All cheat sheets
Cost Governancecheat sheet

AWS Cost Anomaly Detection

Free ML-driven monitors that learn your normal spend and flag deviations within a day or two — catching the runaways you never thought to set a budget on. Narrow per-service monitors catch small spikes broad ones miss.

Last reviewed: July 14, 2026

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

  1. Create one broad "AWS services" monitor as a safety net.
  2. Add per-service monitors for your top 5–8 spenders — this is where the real signal lives; set tighter impact thresholds (~$50–100).
  3. Subscribe with individual SNS alerts (not digest) to a Slack/Teams channel, with a threshold of "$X impact OR Y% deviation, whichever is higher."
  4. In multi-account Orgs, route per-team so anomalies reach the account owner — a single unowned channel gets muted within a month.
  5. 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.

Run this audit with your AI assistant

Paste this into Claude, ChatGPT, or any agent that can run the AWS CLI with read-only credentials. It audits your account for exactly the waste this sheet describes — and changes nothing.

You are auditing an AWS account/Org's Cost Anomaly Detection coverage.
Use the AWS CLI with READ-ONLY credentials. Do not create, modify, or
delete anything — report findings and recommended (unapplied) fixes only.

1. Current monitors: aws ce get-anomaly-monitors and get-anomaly-
   subscriptions — capture monitor types (SERVICE / LINKED_ACCOUNT /
   COST_CATEGORY / TAG), subscription channels, and impact thresholds.
   Flag accounts with NO monitors.
2. Resolution gaps: identify top 5-8 spending services (ce
   get-cost-and-usage, 90 days, group by SERVICE) that lack a dedicated
   per-service monitor — a $200/day spike hides as 2% noise in an
   account-wide monitor but is a 5x event in a per-service one.
3. Routing: flag subscriptions going to a single unowned inbox/channel
   (alerts get muted); recommend per-team SNS routing in multi-account
   orgs. Flag digest-only where individual real-time alerts are wanted.
4. Baseline readiness: note new accounts (<10-14 days) and newly-defined
   cost categories (<14 days) where baselines aren't ready.

Report a table: scope | monitor present? | type | impact threshold |
routing | recommendation. Change nothing.
Works with any assistant that can run shell commands.

Want the guided version?

The AWS Cost Anomaly Detection walkthrough covers this topic interactively — it asks about your setup, branches to what’s relevant, and quizzes you on the tricky parts. Free and anonymous.

Start the walkthrough