Question

Difficulty: HardAuto Scaling and Elasticity

An administrator is configuring a custom step scaling policy for an Amazon EC2 Auto Scaling group (ASG) based on a custom MemoryUtilization metric. The custom metric is collected and sent to Amazon CloudWatch by the CloudWatch agent installed on the EC2 instances. During testing, the administrator notices two issues:

1. Scale-out actions are delayed by up to 5 minutes because the custom metric alarms are evaluated using the default period.
2. Immediately after a scale-out event triggers, the ASG repeatedly launches additional instances before the newly launched instances have finished booting and initializing, causing temporary over-provisioning.

Which two actions should the administrator take to resolve these issues? (Select TWO.)

  1. Modify the CloudWatch alarm to evaluate the metric over a 1-minute period instead of a 5-minute period.Answer
  2. Configure or increase the estimated instance warmup time for the step scaling policy.Answer
  3. C
    Enable detailed monitoring in the Auto Scaling group launch template to increase the reporting frequency of the custom metric to 1 minute.
  4. D
    Increase the default cooldown period of the Auto Scaling group to block subsequent scaling triggers.
  5. E
    Attach an IAM policy with the iam:PassRole permission to the Auto Scaling group's service role to allow the policy to read the metric.

Answer

Modify the CloudWatch alarm to evaluate the metric over a 1-minute period instead of a 5-minute period, and configure or increase the estimated instance warmup time for the step scaling policy.
To resolve the scale-out delay, modifying the CloudWatch alarm to evaluate the metric over a 1-minute period ensures the threshold is checked frequently, aligning with the agent's reporting interval. To resolve the over-provisioning issue, configuring or increasing the estimated instance warmup time prevents the step scaling policy from launching additional instances while existing ones are still booting up.

Step-by-Step Solution

1
Reduce the alarm evaluation latency.
By updating the CloudWatch alarm's period to 60 seconds (1 minute), alarms are evaluated more frequently, resolving the 5-minute scale-out delay.
CloudWatch custom metrics sent by the agent default to 1-minute reporting, but the alarm must also be configured to evaluate at this higher frequency to trigger scaling actions promptly.
2
Prevent premature scaling actions during initialization.
Configuring the estimated instance warmup time on the step scaling policy tells the Auto Scaling group to count these warming instances but ignore their lack of metric reports for subsequent scaling evaluations.
This prevents the step scaling policy from scaling out again while the previously launched instances are still in the process of starting up.

Key Concept

Custom metric scaling configuration and warmup settings in EC2 Auto Scaling step scaling policies.
Rate this question