What should the SysOps administrator do to collect this data?
Use the ALB’s RequestCount metric. Configure a time range of 2 weeks and a period of 1 minute. Examine the chart to determine peak traffic times and volumes.
Use Amazon CloudWatch metric math to generate a sum of request counts for all the EC2 instances over a 2-week period. Sort by a 1-minute interval.
Create Amazon CloudWatch custom metrics on the EC2 launch configuration templates to create aggregated request metrics across all the EC2 instances.
Create an Amazon EventBridge (Amazon CloudWatch Events) rule. Configure an EC2 event matching pattern that creates a metric that is based on EC2 requests. Display the data in a graph.
Explanations:
The ALB’s RequestCount metric provides the total number of requests processed by the load balancer. Configuring a 2-week time range with a 1-minute period allows the SysOps administrator to analyze traffic patterns and identify when the request count exceeded the 100 requests per second threshold.
CloudWatch metric math can be used for aggregating metrics, but there is no need to generate a custom sum of EC2 instance request counts. The ALB’s RequestCount metric already provides the necessary data for request volume across all instances.
Custom metrics on EC2 launch configurations would not be relevant for aggregating request counts across all EC2 instances. This option is unnecessary and adds complexity without providing the needed information from the ALB.
Amazon EventBridge rules are used for event-driven architectures and would not be the appropriate method for tracking request counts. This approach would not directly provide the request volume data from the ALB, which is the needed metric.
I reckon the answer is:
Use the ALB’s RequestCount metric. Configure a time range of 2 weeks and a period of 1 minute. Examine the chart to determine peak traffic times and volumes.