Question

Difficulty: HardAuto Scaling and Elasticity

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?

  1. A
    The Auto Scaling group's default cooldown period is set to 300 seconds, which blocks the step scaling policy from scaling out.
  2. B
    The EventBridge rule routing the metric to the step scaling policy has a default propagation delay of 300 seconds.
  3. The CloudWatch alarm associated with the step scaling policy is configured with a period of 300 seconds instead of 60 seconds.Answer
  4. D
    The 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

1
Analyze how metrics are evaluated by the scaling policy trigger.
The scaling policy is triggered by a CloudWatch alarm, which uses a defined metric, evaluation periods, and period length.
To understand the scaling delay, the administrator must check the alarm configuration rather than the metric publication frequency.
2
Compare the metric publication frequency with the alarm evaluation period.
The custom metric is published every 60 seconds, but the alarm is configured with a 300-second period.
This mismatch means the alarm waits for 300 seconds of data aggregation before evaluating the threshold, causing a 5-minute delay.
3
Rule out incorrect mechanisms like default cooldowns or EventBridge.
Step scaling ignores default cooldowns for scale-out, and EventBridge is not the trigger mechanism for step scaling.
Eliminating these options confirms that the alarm period is the root cause of the delay.

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.
Rate this question