3.2.2.1. Anomaly Detection Alarms (CloudWatch Anomaly Detection)

3.2.2.1. Anomaly Detection Alarms (CloudWatch Anomaly Detection)

Static thresholds break when traffic patterns are dynamic. An alarm at "CPU > 80%" fires falsely during expected peak hours and misses anomalies during off-peak.

CloudWatch Anomaly Detection uses ML to learn a metric's expected pattern — daily, weekly, and seasonal cycles. It creates a band of expected values, and you alarm when the metric breaches the band.

# Create anomaly detection alarm for API latency
aws cloudwatch put-metric-alarm \
  --alarm-name "LatencyAnomaly" \
  --metric-name "TargetResponseTime" \
  --namespace "AWS/ApplicationELB" \
  --dimensions Name=LoadBalancer,Value=app/my-alb/1234 \
  --comparison-operator LessThanLowerOrGreaterThanUpperThreshold \
  --threshold-metric-id "ad1" \
  --metrics '[
    {"Id": "m1", "MetricStat": {"Metric": {"Namespace": "AWS/ApplicationELB", "MetricName": "TargetResponseTime", "Dimensions": [{"Name": "LoadBalancer", "Value": "app/my-alb/1234"}]}, "Period": 300, "Stat": "Average"}},
    {"Id": "ad1", "Expression": "ANOMALY_DETECTION_BAND(m1, 2)"}
  ]' \
  --evaluation-periods 3 \
  --datapoints-to-alarm 2

Anomaly detection vs. static thresholds:

Exam Trap: Anomaly detection requires approximately 2 weeks of data to build an accurate model. During the training period, the band may be too wide (missing anomalies) or too narrow (false alarms). For critical metrics, use static threshold alarms during the training period and switch to anomaly detection once the model stabilizes.