A SysOps Administrator is configuring an Amazon CloudWatch alarm to trigger a scale-out policy for an Auto Scaling group when the average CPU utilization exceeds 75%. The EC2 instances are launched using a template with default monitoring. The administrator sets the CloudWatch alarm period to 1 minute and the evaluation periods to 3. However, after a traffic spike, the scaling policy does not execute, and the CloudWatch alarm remains in the INSUFFICIENT_DATA state. Which action will resolve this issue and allow the alarm to transition to the ALARM state?
- Enable detailed monitoring in the launch template used by the Auto Scaling group.Answer
- BReduce the Auto Scaling group cooldown period to 60 seconds to align with the alarm period.
- CConfigure the alarm to use a high-resolution period of 10 seconds for the CPUUtilization metric.
- DCreate an Amazon EventBridge rule that monitors the CPUUtilization metric and targets the scaling policy directly.
Answer
Enable detailed monitoring in the launch template used by the Auto Scaling group.
Enabling detailed monitoring in the launch template ensures that the EC2 instances publish metrics to CloudWatch every 1 minute instead of the default 5 minutes. This satisfies the alarm's configuration of a 1-minute period with 3 evaluation periods, allowing the alarm to retrieve enough data points to evaluate its state and trigger the scaling policy.
Step-by-Step Solution
Key Concept
CloudWatch Metric Granularity for EC2 Instances
Estimated Time:1m 30s