DevOps Peach

AWS Basics · Monitoring – CloudWatch, CloudTrail, and AWS Config · Lesson 3 of 5

CloudWatch Alarms and EventBridge

Design alarm actions, EC2 recovery, and event rules.

Practice interactively →

Alarms evaluate metrics over windows

An alarm has OK, ALARM, and INSUFFICIENT_DATA states. Evaluation periods and datapoints-to-alarm determine how many breaching periods are required (for example 3 out of 5); missing-data behavior should match the metric.

flowchart LR
  M["Metric<br/>CPUUtilization"] --> A["Alarm<br/>> 80% for 3 of 5 periods"]
  A --> SNS["SNS topic<br/>email, Slack, pager"]
  A --> ASG["Auto Scaling<br/>add instances"]
  A --> EC2["EC2 action<br/>recover, reboot"]
  EV["AWS event<br/>instance stopped"] --> EB["EventBridge rule<br/>pattern match"]
  EB --> L["Lambda, SQS, SNS<br/>targets"]
  %% step M: An alarm watches one metric, or a metric math expression.
  %% step A: It changes state only when enough datapoints breach the threshold, which avoids alerting on one spike.
  %% step SNS: In ALARM it can notify a topic; subscribers get an email or a chat message.
  %% step ASG: The same alarm can drive a scaling policy.
  %% step EC2: Or an EC2 action such as recovering an instance onto new hardware.
  %% step EV: Separately, AWS services emit events whenever something happens.
  %% step EB: An EventBridge rule matches events by pattern, or runs on a schedule.
  %% step L: Matching events are delivered as JSON to targets such as Lambda or SQS.

Alarm settings

Setting Meaning
Period Length of each datapoint window, e.g. 60 or 300 seconds
Evaluation periods (N) How many recent periods are looked at
Datapoints to alarm (M) How many of those N must breach — "M out of N"
Missing data missing, notBreaching, breaching, or ignore
Actions Per state: ALARM, OK, INSUFFICIENT_DATA

An SNS email subscription must be confirmed before receiving alarm notifications. INSUFFICIENT_DATA commonly means too few datapoints or a wrong dimension, not necessarily a service failure. For metrics that report only when something happens (errors), treat missing data as notBreaching.

Composite alarms combine other alarms with AND/OR, reducing noise: page only when high latency AND high error rate occur together. Anomaly detection alarms learn a metric's normal band instead of a fixed threshold.

EC2 status alarms

An EC2 system status check covers underlying AWS infrastructure; an instance status check covers the guest OS or networking. A recover action on StatusCheckFailed_System moves an instance to healthy hardware in supported cases while preserving instance ID, private IPs, Elastic IPs and EBS volumes. A reboot action suits instance-check failures.

EventBridge

CloudWatch Events is now Amazon EventBridge. A rule matches an event pattern or schedule and sends event JSON to a target:

{"source": ["aws.ec2"], "detail-type": ["EC2 Instance State-change Notification"],
 "detail": {"state": ["stopped", "terminated"]}}

Targets include Lambda, SQS, SNS, Step Functions, ECS tasks and other event buses. EventBridge Scheduler runs one-time or recurring jobs (cron or rate) at scale. Alarms react to metric values; EventBridge reacts to things that happened, such as an instance stopping, a CloudTrail API call, or a GuardDuty finding.

Command Purpose
aws cloudwatch put-metric-alarm --alarm-name cpu-high --namespace AWS/EC2 --metric-name CPUUtilization --dimensions Name=InstanceId,Value=i-0123 --statistic Average --period 300 --evaluation-periods 5 --datapoints-to-alarm 3 --threshold 80 --comparison-operator GreaterThanThreshold --alarm-actions arn:aws:sns:...:ops Create an alarm
aws cloudwatch set-alarm-state --alarm-name cpu-high --state-value ALARM --state-reason test Test state and action
aws events put-rule --name ec2-stopped --event-pattern file://pattern.json Create an EventBridge rule

Traps: forgetting to confirm the SNS email; alarming on a single datapoint and getting paged for blips; reading INSUFFICIENT_DATA as an outage.

Practice interactively →