CloudWatch Alarms and Composite Alarms

A CloudWatch alarm monitors a single metric or the result of a metric math expression over a time period you specify. When the metric crosses a threshold you define, the alarm changes state and can automatically trigger an action such as sending an SNS notification, scaling an Auto Scaling group, stopping an EC2 instance, or executing a Systems Manager OpsItem. Alarms are the primary mechanism for automated operational response in AWS.

A CloudWatch alarm is always in one of three states: OK — the metric is within the defined threshold; ALARM — the metric has breached the threshold for the required number of evaluation periods; INSUFFICIENT_DATA — the alarm has just been created, the metric is not available, or not enough data has been collected yet. Transitions between states trigger actions configured for that state change — you can have different SNS topics for OK, ALARM, and INSUFFICIENT_DATA states.

When creating an alarm you specify: the metric and namespace, the statistic (Average, Sum, Maximum, etc.), the period (how often the metric is evaluated in seconds), the evaluation periods (how many consecutive periods must breach the threshold), the threshold value, and the comparison operator. The alarm triggers when the metric breaches the threshold for the specified number of consecutive evaluation periods.

Alarm actions can target several destinations: Amazon SNS topics (to send email, SMS, or trigger Lambda), Auto Scaling policies (to scale in or scale out an ASG), and EC2 actions (to stop, terminate, reboot, or recover an EC2 instance). For each state (OK, ALARM, INSUFFICIENT_DATA) you can specify a different set of actions — for example, notify the team on ALARM, notify on recovery with OK, and alert on INSUFFICIENT_DATA to catch monitoring gaps.

When CloudWatch evaluates an alarm and some data points are missing, you must decide how to treat them. Options are: notBreaching (treat missing data as within threshold — alarm stays OK if other data is OK), breaching (treat missing as exceeding threshold — alarm moves to ALARM), ignore (the alarm state doesn't change), and missing (alarm moves to INSUFFICIENT_DATA). Choosing the wrong option leads to false positives or silent failures — a key SAA-C03 exam nuance.

The alarm resolution is the product of period × evaluation-periods. For example, a period of 60 seconds with 5 evaluation periods means the alarm considers 5 consecutive 1-minute data points. The alarm only transitions to ALARM when all five periods breach the threshold (by default). You can configure datapoints-to-alarm to require only M out of N periods to breach — for example, 3 out of 5 — which reduces false positives from transient spikes.

A composite alarm evaluates the state of multiple other alarms using Boolean logic (AND, OR, NOT). It enters the ALARM state only when its rule expression evaluates to true. Composite alarms are used to reduce alert noise — for example, only alert if BOTH high CPU AND high latency alarms are firing simultaneously, because high CPU alone may be acceptable during batch processing. You can also use composite alarms to suppress child alarms during maintenance windows.

Composite alarms support alarm suppression actions — you can configure a composite alarm to suppress its child alarms during planned maintenance. For example, during a deployment window you might set a composite alarm that combines a 'MaintenanceMode' alarm with OR logic, suppressing all child alarm notifications while maintenance is active. This prevents an avalanche of alerts when you intentionally take services offline for upgrades.

Auto Scaling groups use CloudWatch alarms as triggers for step scaling and simple scaling policies. When the alarm enters the ALARM state, the scaling policy executes. For step scaling, you define multiple scaling adjustments for different threshold ranges — for example, add 1 instance if CPU is 70-80%, add 3 if CPU is 80-90%, add 5 if CPU is above 90%. The alarm triggers the first applicable step based on the breach level at evaluation time.

You can create billing alarms in CloudWatch to be notified when your estimated AWS charges exceed a threshold. Billing metrics are only published in the us-east-1 Region (regardless of where your resources run) and are updated approximately every 6 hours. To enable billing alarms, you must first turn on Billing Alerts in the AWS Billing console. The more precise tool is AWS Budgets, but CloudWatch billing alarms remain a valid option tested in the exam.

You can manually set an alarm state using the set-alarm-state command to test alarm actions without waiting for a real threshold breach. This is useful for verifying that your SNS topics, Auto Scaling policies, and Lambda functions respond correctly. Always test your alarm actions in a non-production environment and verify that the SNS topic has the correct email subscriptions confirmed before relying on alarms for production alerting.

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

In this lesson you learned: alarms have three states (OK, ALARM, INSUFFICIENT_DATA) and can trigger SNS, Auto Scaling, and EC2 actions, datapoints-to-alarm allows M-of-N evaluation to reduce false positives, and composite alarms use Boolean logic to combine multiple alarms and suppress alert noise. Next up we explore CloudWatch Logs and Log Insights for centralised log management.