Soru

Zorluk: ZorAuto Scaling and Elasticity

A SysOps administrator manages an Amazon EC2 Auto Scaling group (ASG) behind an Application Load Balancer. The ASG is configured with a target tracking scaling policy based on the ASGAverageCPUUtilizationASGAverageCPUUtilization metric at a target value of 60%60\%. Standard monitoring is enabled on the EC2 instances in the launch template. During sudden traffic spikes, CPU utilization rises to 90%90\%, triggering a scale-out. However, the administrator observes that the ASG launches multiple consecutive batches of instances before the first batch has finished initializing and registering with the load balancer, leading to significant over-provisioning. The application on the instances requires 44 minutes to become fully operational and begin processing requests. Which action should the administrator take to prevent this over-provisioning behavior?

  1. Enable detailed monitoring in the launch template used by the ASG, and configure the estimated instance warm-up for the target tracking scaling policy to 240 seconds.Cevap
  2. B
    Keep standard monitoring enabled, and reduce the target tracking scaling policy's estimated instance warm-up to 60 seconds to allow the ASG to recalculate the metrics more frequently.
  3. C
    Increase the default cooldown period of the Auto Scaling group to 240 seconds to prevent the group from executing subsequent scale-out actions while instances are initializing.
  4. D
    Modify the EC2 instance profile role to grant the iam:PassRole permission to the Auto Scaling service, ensuring that the instances can pass their monitoring roles to CloudWatch without delay.

Cevap

Enable detailed monitoring in the launch template used by the ASG, and configure the estimated instance warm-up for the target tracking scaling policy to 240 seconds.
Enabling detailed monitoring ensures that EC2 CPU utilization metrics are sent to CloudWatch at 1-minute intervals. Configuring the estimated instance warm-up to 240 seconds (4 minutes) ensures that the target tracking policy does not perform another scaling evaluation until the new instances have finished booting and their impact on the average CPU utilization is reflected in the 1-minute metric updates.

Adım Adım Çözüm

1
Analyze the metric reporting frequency.
Standard monitoring updates metrics at 5-minute (300 seconds) intervals, which is longer than the 4 minutes (240 seconds) the application needs to boot.
To prevent the scaling policy from evaluating stale data, the metric evaluation frequency must match or exceed the scaling policy evaluation intervals.
2
Identify the scaling policy control parameter for scale-out actions.
Target tracking scaling policies use the 'estimated instance warm-up' parameter to determine how long to wait before counting newly launched instances toward the group's metrics.
The ASG's default cooldown is ignored for scale-out actions in target tracking policies.
3
Align the warm-up period with the actual initialization time.
Set the estimated instance warm-up to 240 seconds.
This blocks the policy from performing further scale-out evaluations until the new instances have had 4 minutes to boot.
4
Enable detailed monitoring in the launch template.
Metrics are now sent to CloudWatch at 1-minute intervals.
Detailed monitoring ensures that once the 240-second warm-up ends, CloudWatch has fresh metrics showing the reduced average CPU utilization, preventing subsequent redundant launches.

Anahtar Kavram

Auto Scaling Target Tracking Warm-up and Monitoring Granularity
Tahmini Süre:2m 0s
Bu soruyu puanla