A SysOps administrator is troubleshooting an Amazon EC2 Auto Scaling group (ASG) that is scaling out too slowly during sudden traffic spikes. The ASG is configured with a step scaling policy based on the average CPU utilization of the group. The associated CloudWatch alarm has a period of 60 seconds and an evaluation period of 1. However, during high-load events, the ASG takes approximately 5 minutes to trigger the scale-out action. What is the root cause of this delay?
- Detailed monitoring is disabled in the launch template, resulting in EC2 metric data being sent to CloudWatch at 5-minute intervals.Cevap
- BThe default cooldown period of the Auto Scaling group is set to 300 seconds, which blocks the initial metric evaluation and alarm execution.
- CThe Amazon EventBridge rule routing the alarm state change to the Auto Scaling group has a default propagation latency of 5 minutes.
- DThe IAM role assigned to the Auto Scaling group is missing the iam:PassRole permission, causing AWS to fall back to a 5-minute polling interval.
Cevap
Detailed monitoring is disabled in the launch template, resulting in EC2 metric data being sent to CloudWatch at 5-minute intervals.
The correct answer is that detailed monitoring is disabled. By default, EC2 instances are configured with standard monitoring, which sends metrics to CloudWatch at 5-minute intervals. Even if a CloudWatch alarm is configured with a 1-minute period, it cannot evaluate new data points faster than they are sent. To achieve 1-minute scaling response times, detailed monitoring must be enabled on the EC2 instances via the launch template.
Adım Adım Çözüm
Anahtar Kavram
Auto Scaling policies rely on the resolution of the underlying CloudWatch metrics. Without detailed monitoring enabled, EC2 metrics are sent at 5-minute intervals, delaying alarm evaluation and subsequent scaling actions.
Tahmini Süre:2m 0s