Question

Difficulty: MediumCloudWatch Metrics and Alarms

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?

  1. A
    An Amazon EventBridge rule has not been configured to route the ALARM state change event from CloudWatch to the Auto Scaling dynamic scaling policy.
  2. B
    The SysOps Administrator failed to enable detailed monitoring within the CloudWatch console's alarm configuration settings.
  3. The EC2 instances in the Auto Scaling group are using standard monitoring, which publishes CPU utilization metrics to CloudWatch at 5-minute intervals.Answer
  4. D
    The Auto Scaling group's cooldown period is shorter than the 3-minute alarm evaluation window, which causes the scaling action to be ignored.

Answer

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.

Step-by-Step Solution

1
Analyze the configured evaluation criteria of the CloudWatch alarm.
The alarm is configured with a period of 60 seconds and requires 3 consecutive periods, resulting in a minimum evaluation window of 3 minutes.
This establishes the minimum time window required for the alarm to change state.
2
Examine the default metric delivery intervals for Amazon EC2 instances.
Under standard monitoring, EC2 instances send metrics to CloudWatch at a 5-minute interval.
This determines how frequently new data points are published to the metric stream.
3
Determine the impact of the monitoring frequency on the alarm's evaluation window.
With standard monitoring, CloudWatch only receives new metrics every 5 minutes. The 1-minute alarm cannot collect 3 consecutive 1-minute data points in a 3-minute span because the data points do not exist yet, preventing the alarm from triggering within 3 minutes.
This explains why the alarm did not trigger within the expected 3 minutes.

Key Concept

Standard versus detailed monitoring intervals and their impact on CloudWatch metric alarm evaluations.
Rate this question