A company hosts a processing application on Amazon EC2 instances in an Auto Scaling group (ASG). A SysOps administrator configures a step scaling policy based on a custom CloudWatch metric named QueueBacklog, which is published by the application every 60 seconds. During sudden load spikes, the administrator notices that although the metric exceeds the alarm threshold almost immediately, the ASG takes 5 minutes before launching new instances.
What is the most likely cause of this delay in scaling?
- AThe Auto Scaling group's default cooldown period is set to 300 seconds, which blocks the step scaling policy from scaling out.
- BThe EventBridge rule routing the metric to the step scaling policy has a default propagation delay of 300 seconds.
- The CloudWatch alarm associated with the step scaling policy is configured with a period of 300 seconds instead of 60 seconds.Answer
- DThe IAM role assigned to the Auto Scaling group is missing the iam:PassRole permission for the CloudWatch namespace.
Answer
The CloudWatch alarm associated with the step scaling policy is configured with a period of 300 seconds instead of 60 seconds.
The correct answer is correct because CloudWatch alarms evaluate metrics over a specified period. Even if the application publishes the custom metric every 60 seconds, an alarm with a period of 300 seconds (5 minutes) will only evaluate the metric at 5-minute intervals. To reduce scaling latency, the alarm's period must be set to 60 seconds (1 minute) to match the publication frequency of the metric.
Step-by-Step Solution
Key Concept
Auto Scaling policies rely on CloudWatch alarms. If the alarm period is larger than the metric publication interval, scaling decisions will be delayed because the alarm aggregates data over that longer period.