Examkin

Question

Difficulty: Very hardAuto Scaling and Elasticity

A SysOps administrator is managing an application running on Amazon EC2 instances inside an Auto Scaling group (ASG). The ASG uses a target tracking scaling policy based on the default `ASGAverageCPUUtilization` metric, with a target utilization of 50%50\%. The application experiences sudden, high-intensity traffic spikes that typically last for 1010 to 1515 minutes. However, during these spikes, the ASG takes 55 to 77 minutes to begin launching new instances, causing the existing instances to become overloaded and fail health checks. The launch template for the ASG does not explicitly configure monitoring.

Which of the following describes the root cause of this delayed scaling behavior, and the correct remediation step?

  1. A
    The default instance warmup period for the target tracking policy is set to the default value of 300300 seconds, preventing the ASG from launching new instances until the warmup expires. The administrator should decrease the default cooldown period of the Auto Scaling group to 6060 seconds.
  2. The EC2 instances are reporting metrics at the default 55-minute interval, causing a delay in the aggregation of the `ASGAverageCPUUtilization` metric. The administrator should enable detailed monitoring in the launch template.Answer
  3. C
    The Auto Scaling group metrics collection is disabled, which prevents CloudWatch from gathering metrics at a 11-minute frequency. The administrator should enable group metrics collection in the Auto Scaling group configuration.
  4. D
    The service-linked role for Auto Scaling lacks the `iam:PassRole` permission to pass the execution role to the new instances, causing CloudWatch alarm action executions to time out. The administrator should attach a policy allowing `iam:PassRole` to the Auto Scaling service role.

Answer

The correct answer is that the EC2 instances are reporting metrics at the default 55-minute interval, and detailed monitoring must be enabled in the launch template.
The correct answer is the option indicating that the instances are reporting metrics at the default 55-minute interval, and detailed monitoring must be enabled in the launch template. By default, EC2 instances send CPU utilization metrics to CloudWatch every 55 minutes. Because target tracking scaling policies rely on the aggregated `ASGAverageCPUUtilization` metric, the underlying alarm is bound by this 55-minute reporting interval. Consequently, a sudden load spike is not registered quickly enough, leading to a scaling delay. Enabling detailed monitoring in the launch template changes this reporting interval to 11 minute, resolving the delay.

Step-by-Step Solution

1
Analyze the metrics source and default monitoring settings for Amazon EC2 instances.
Identify that by default, standard monitoring is active, which sends CPU metrics to Amazon CloudWatch at 55-minute intervals.
Target tracking scaling policies evaluate aggregated metrics like `ASGAverageCPUUtilization` that rely on individual instance metrics.
2
Evaluate the delay in metric updates during traffic spikes.
Determine that a traffic spike starting right after a metric push can take up to 55 minutes to be reflected in CloudWatch, delaying alarm breach.
Without detailed monitoring, CloudWatch does not receive the granular data needed to trigger scale-out actions within 11 to 22 minutes.
3
Formulate the remediation strategy.
Enable detailed monitoring in the launch template to change the metric delivery interval to 11 minute.
This ensures the `ASGAverageCPUUtilization` metric is updated every minute, allowing the target tracking policy to trigger scaling quickly.

Key Concept

The difference between Standard and Detailed Monitoring on EC2 instances and its impact on Auto Scaling responsiveness.
Estimated Time:3m 0s
Rate this question

Topics

Auto Scaling and Elasticity

More questions from this topic