TL;DR: Budgets fire when you cross a line you drew — but only if you knew where to draw it. Cost Anomaly Detection is the free, ML-driven layer that catches what you didn't anticipate: a retry loop that 30×'s S3 PUTs overnight, a feature that quietly triples DataTransfer-Out. You create monitors scoped to a slice of spend; each learns a baseline and alerts when daily cost deviates from the established pattern — not just its magnitude. The key insight most people miss: narrow monitors catch far smaller spikes than broad ones.
The numbers
- Free — AWS doesn't charge for anomaly detection.
- Four monitor types: AWS services (coarse default), linked accounts (per member account), cost categories, cost allocation tags.
- Resolution: a $200/day Lambda spike is a 5× event to a per-service Lambda monitor but 2% noise inside a $10,000/day account-wide monitor — the narrow monitor catches it, the broad one misses it.
- Warm-up: ~10–14 days of history for a useful baseline; cost-category monitors need the category defined ~14 days first.
- Detection cadence is daily — a spike must persist ~24 hours to be caught (a 2-hour runaway may never trigger; use CloudWatch billing alarms for sub-day).
- Field examples: an infinite Lambda retry loop ($5→$180/day) caught next morning, ~$200 damage instead of $4,000+; a forgotten staging cluster surfaced as a sustained step-change anomaly, ~$1,200/mo saved.
Do this
- Create one broad "AWS services" monitor as a safety net.
- Add per-service monitors for your top 5–8 spenders — this is where the real signal lives; set tighter impact thresholds (~$50–100).
- Subscribe with individual SNS alerts (not digest) to a Slack/Teams channel, with a threshold of "$X impact OR Y% deviation, whichever is higher."
- In multi-account Orgs, route per-team so anomalies reach the account owner — a single unowned channel gets muted within a month.
- Wait 10–14 days before tuning, then ratchet thresholds down and mark false positives in the console so the model adapts; a well-tuned setup fires ~1–2×/week.
Gotchas
- First 10–14 days are useless or noisy — don't tune yet; just wait for the baseline.
- Daily rollup means short spikes slip through — a 2-hour runaway can be flat by detection time; pair with CloudWatch alarms for sub-day protection.
- Negative anomalies are flagged too — a sudden drop can be benign (workload finished) or real (an autoscaling group that should be running isn't); don't auto-dismiss.
- Tag-based monitors need activated cost allocation tags — the most common "why isn't this working" cause.
Skip this if
- Nothing to skip — it's free and catches the long tail no fixed threshold covers. It's complementary, not a replacement: AWS Budgets enforces the limits you can predict, this catches the ones you can't, AWS Cost Explorer is the post-alert investigation tool, and Cost and Usage Reports with Athena is the deep dive when an anomaly doesn't fit any of them.