A SysOps Administrator is managing an Amazon EC2 Auto Scaling group and configures a dynamic scaling policy to scale out when average CPU utilization exceeds 75%. The administrator sets up a CloudWatch metric alarm to monitor the CPUUtilization metric with a period of 60 seconds and an evaluation period of 3 consecutive data points. During a load testing phase, traffic is increased, but the scaling policy fails to trigger within the expected 3-minute window, even though the actual CPU load is sustained above 80% on all instances. Which of the following is the most likely cause of this issue?
- AAn Amazon EventBridge rule has not been configured to route the ALARM state change event from CloudWatch to the Auto Scaling dynamic scaling policy.
- BThe SysOps Administrator failed to enable detailed monitoring within the CloudWatch console's alarm configuration settings.
- The EC2 instances in the Auto Scaling group are using standard monitoring, which publishes CPU utilization metrics to CloudWatch at 5-minute intervals.Cevap
- DThe Auto Scaling group's cooldown period is shorter than the 3-minute alarm evaluation window, which causes the scaling action to be ignored.
Cevap
The EC2 instances in the Auto Scaling group are using standard monitoring, which publishes CPU utilization metrics to CloudWatch at 5-minute intervals.
The correct answer is that the instances are using standard monitoring. Because standard monitoring only publishes metrics to CloudWatch every 5 minutes, a CloudWatch alarm with a 1-minute period will not receive new metric values each minute. Consequently, the alarm cannot gather the 3 consecutive 1-minute data points required to transition to the ALARM state within the expected 3 minutes.
Adım Adım Çözüm
Anahtar Kavram
Standard versus detailed monitoring intervals and their impact on CloudWatch metric alarm evaluations.