3.2.3.3. Alert Notification & Action Capabilities (CloudWatch Alarms to SNS/Lambda, EC2 automatic recovery)

3.2.3.3. CloudWatch Alarms, Custom Metrics & Notifications

Alarms bridge monitoring and automation. A well-configured alarm detects issues early and triggers the right response without human intervention.

Alarm configuration best practices:

# High-severity alarm: API error rate > 5% for 2 of 3 periods
aws cloudwatch put-metric-alarm \
  --alarm-name "API-HighErrorRate" \
  --metric-name "5XXError" \
  --namespace "AWS/ApplicationELB" \
  --statistic Sum \
  --period 60 \
  --evaluation-periods 3 \
  --datapoints-to-alarm 2 \
  --threshold 50 \
  --comparison-operator GreaterThanThreshold \
  --alarm-actions "arn:aws:sns:us-east-1:123456789012:ops-alerts" \
  --ok-actions "arn:aws:sns:us-east-1:123456789012:ops-resolved" \
  --treat-missing-data notBreaching

treat-missing-data options:

• missing: Maintain current state (default)
• notBreaching: Missing = OK. Use for metrics that stop when everything is fine.
• breaching: Missing = ALARM. Use for heartbeat metrics that should always report.
• ignore: Don't evaluate missing points.

Notification architecture:

• SNS → Email/SMS: Simple alerting for ops teams
• SNS → Lambda → Slack/PagerDuty: Formatted notifications with context
• SNS → SQS → Consumer: Buffered processing for high-volume alerts
• Alarm → Auto Scaling: Direct integration, no SNS needed

Exam Trap: treat-missing-data is critical for alarms on sporadic metrics. If a Lambda function only runs occasionally, its error metric has no data points between invocations. With the default missing setting, the alarm stays in INSUFFICIENT_DATA. Set notBreaching so the alarm reports OK when no invocations occur, and only fires when errors actually appear.