Creating Alarms and Notifications

A CloudWatch alarm watches a single metric and changes state when the value crosses a threshold you define over a period of time. Its job is to convert a number that breaches a limit into an action, most often a notification. Alarms are how monitoring becomes alerting.

An alarm is always in one of three states: OK when the metric is within bounds, ALARM when the threshold is breached, and INSUFFICIENT_DATA when there is not enough data to decide. Actions can be attached to any state transition, so you can notify both when trouble starts and when it clears.

You configure the statistic (such as Sum or Average), the period (the length of each data window), and the number of evaluation periods that must breach before the alarm fires. Requiring several consecutive bad periods reduces false alarms from brief spikes, while a single period gives the fastest possible alert.

Alarms do not send email themselves. They publish to Amazon SNS (Simple Notification Service), a pub/sub service. An SNS topic has subscribers such as email addresses, SMS numbers, or Lambda functions. The alarm notifies the topic, and SNS fans the message out to everyone subscribed.

Notification is not the only action. An alarm can invoke an EC2 action, an Auto Scaling action, or, through SNS or EventBridge, a Lambda function. This lets a security alarm do more than page someone: it can kick off an automated containment workflow the instant a threshold is crossed.

A composite alarm combines several alarms using AND/OR logic into one parent. This cuts alarm noise: instead of three separate pages, you fire once only when a meaningful combination is true. It is useful for reducing alert fatigue while still keeping each underlying alarm available for detail.

The SNS topic is part of your alert chain, so protect it. Use a topic access policy to control who can publish and subscribe, and consider server-side encryption with KMS for sensitive alert content. An attacker who can subscribe to your alert topic learns exactly what you are watching for.

Instead of a fixed threshold, an alarm can use CloudWatch anomaly detection, which learns a metric's normal range and alerts on deviations from a band. This suits metrics with daily or weekly patterns where a static number would either miss problems or fire constantly. It adapts as behavior shifts over time.

You decide how an alarm treats missing data: as good, bad, ignored, or as keeping the current state. For security alarms this matters. If your logging stops because an attacker disabled it, treating missing data as "breaching" can turn silence into a signal rather than a blind spot.

Good security alarms are specific, well tuned, and routed to a channel humans watch. Too many noisy alarms train teams to ignore them. Use few evaluation periods for critical events like root login so the alert is immediate, and pair alarms with automation so the most dangerous events get a response before anyone reads the email.

The full chain is: a log line matched by a metric filter increments a metric, a CloudWatch alarm watches that metric, and on breach it notifies an SNS topic that pages your team and optionally triggers Lambda. Mastering this flow is essential for the logging and monitoring domain of the exam.

Test your alarm knowledge.

A CloudWatch alarm watches one metric and moves between OK, ALARM, and INSUFFICIENT_DATA based on a threshold over evaluation periods. On breach it publishes to an SNS topic that fans out to subscribers or triggers automation. Composite alarms cut noise, anomaly detection adapts to patterns, and careful missing-data handling turns logging gaps into signals.