Alarms and Automated Actions
~8 min read
How an alarm decides when to fire, and what it can actually do about it.
A CloudWatch Alarm watches a single metric (or, with metric math, a computed combination of metrics) against a threshold over an evaluation period — e.g. 'average CPU utilization above 80% for 3 out of the last 3 five-minute periods.' Requiring multiple consecutive breaching periods ('datapoints to alarm') rather than reacting to a single data point is standard practice to avoid over-reacting to brief, harmless noise.
Once in ALARM state, an alarm can trigger one or more actions: publishing to an SNS topic (for human notification via email/SMS/chat integration), directly triggering an Auto Scaling policy (adding or removing capacity), or invoking an EC2 action (like rebooting or recovering an impaired instance). The same underlying alarm mechanism powers both human-facing alerting and fully automated infrastructure responses — the difference is purely which action(s) you attach.
Composite alarms combine multiple individual alarms with AND/OR logic into a single higher-level alarm state — useful for reducing alert noise by only notifying when several related conditions are true simultaneously (e.g. both high error rate AND high latency, rather than firing separately for each and potentially causing alert fatigue from two notifications describing what's really one underlying incident).
💬 Deep Dive with AI
Key points
- •Alarms evaluate a metric against a threshold over a defined evaluation period, typically requiring multiple consecutive breaches
- •Actions include SNS notification, Auto Scaling triggers, and EC2 recovery actions — the same mechanism for both human alerts and automation
- •Composite alarms combine multiple alarms with AND/OR logic to reduce noise from related conditions
- •Well-tuned thresholds come from actual historical metric behavior, not arbitrary guesses