Here's a postmortem that gets written every month somewhere: a misconfigured NAT gateway (or a recursive Lambda, or a debug-level log group) starts adding $400 a day to the bill. Nobody notices for three weeks. The invoice lands, someone asks "why didn't we get an alert", and the answer turns out to be embarrassing: there were two alerting systems, both enabled, both at settings nobody had thought about. The budget alert was set to fire at 100% of a number from last year. The anomaly detector was left at a $500 threshold someone clicked through during setup.
Most AWS cost alerting fails in one of exactly two ways: it never fires, or it fires so often that Slack mutes it. Both failures come from the same place. The tools are fine; the thresholds are unset, defaulted, or copied from a blog that never printed a number.
So this post prints the numbers.
Two tools, two different questions
AWS Budgets answers: did cumulative spend cross a line I drew in advance? It's absolute and top-down. You say "$66,000 this month", and it tracks actual and forecasted spend against that line. It is very good at catching the slow version of disaster: spend drifting 8% up month over month until the quarter is blown.
AWS Cost Anomaly Detection answers: does today's spend look unlike this workload's own past? It's relative and bottom-up. It learns a baseline per service (or per account, cost category, or tag, depending on the monitor) and flags deviations from expected. It is very good at catching the fast version of disaster: the NAT gateway that doubled overnight.
Each one is blind exactly where the other sees:
- Budgets can't see a spike hiding inside an under-budget month. If you budgeted $66k and a leak burns $8k in week one of an otherwise-$55k month, the 100% alert stays silent until it's far too late to call it an alert.
- Anomaly detection can't see slow creep. The baseline adapts. A 3%-per-week leak is never anomalous on any given day; it just quietly becomes the new normal. The detector is doing its job correctly and you still lose.
So the answer to "which one" is boring: both, they're both free to turn on (more on pricing in the FAQ), and the entire game is what thresholds you give them.
The thresholds for Cost Anomaly Detection
Setup first, because monitor choice changes what the thresholds mean: use one AWS services monitor (it builds a baseline per service, which is where anomalies actually live), and add linked-account or cost-allocation-tag monitors only if teams need separately routed alerts.
Then create two subscriptions, not one:
- A "page" subscription: individual alerts, sent to SNS (and into Slack via Chatbot). This is the one that interrupts a human.
- A "digest" subscription: the daily summary email, with a much lower bar. This is the one you scan with coffee.
For the page subscription, the single most important setting is one most people never touch: combine the two threshold types with AND, not OR.
- Absolute-only misses proportional blowups on mid-size services.
- Percentage-only buries you: a $20/month service doubling is a 100% anomaly worth $20, and a $80,000/day service wobbling 3% is a $2,400 "anomaly" that's actually just Tuesday.
- AND requires both "big enough to matter" and "weird enough to be real". That combination is what kills the noise.
The numbers, tiered by monthly AWS bill:
| Monthly bill | Typical daily spend | Page alert (impact AND deviation) | Daily digest floor |
|---|---|---|---|
| ~$3k | ~$100 | ≥ $50 AND ≥ 40% | ≥ $10 |
| ~$30k | ~$1,000 | ≥ $100 AND ≥ 25% | ≥ $25 |
| ~$300k | ~$10,000 | ≥ $500 AND ≥ 15% | ≥ $100 |
| ~$3M | ~$100,000 | ≥ $2,500 AND ≥ 10% | ≥ $500 |
The formula behind the table, if your bill sits between rows: set the absolute floor around 5% of a typical day's spend (minimum $50), and the percentage between 10% and 40%, tighter as the bill grows (large bills have smoother baselines, so smaller relative moves are more meaningful).
Expected outcome at these settings: the page fires a few times a month, and when it fires you actually stand up. If it's firing daily, raise the absolute floor before touching the percentage; the noise is almost always small-dollar services having proportionally dramatic days.
The thresholds for Budgets
Budget amount: 1.1 × your trailing 3-month average, revisited quarterly, unless you have a genuine committed plan number. A budget copied from last year is a random number generator with a dollar sign.
Then a ladder of alerts on that budget:
- 80% of actual: the pacing check. If this fires before day 24 of the month, you're running hot.
- 100% of forecasted: the alert that matters most. AWS projects month-end spend from the pace so far; this fires the moment the trajectory crosses the line, which is typically weeks before actual does. (Forecast alerts need about five weeks of history before AWS will arm them.)
- 100% of actual: the breach record, mostly for the retro.
Two additions that cost nothing and catch entire categories of problems:
- Zero-spend budgets on accounts that should be empty: the sandbox that was "cleaned up", the old prod account after a migration. AWS has a template that alerts the moment spend exceeds $0.01. Silence from these accounts is the point.
- Action budgets on sandboxes only: at 100%, attach a budget action that applies a deny-new-resources policy or stops tagged instances. Never wire automatic stop actions to production; wire them to the accounts where an outage is a shrug.
Budgets are per-account tools as much as org tools. One org-wide budget hides everything; a budget per account (or per team's cost category) is where the 80% alert starts meaning something.
What fires when: one leak, four detection layers
Take the $60k/month org ($2k/day) and give it a real incident: a NAT gateway misroute starts pushing $400/day of data processing on a service line that normally runs $150/day.
| Layer | Fires | Leak spend by then |
|---|---|---|
| Anomaly page alert ($100 AND 25%) | Day 1-2, once the day's data lands ($400 impact, +267% deviation) | $400-800 |
| Budget, 100% forecasted ($66k) | Around day 8-10, when trajectory crosses | ~$3,500 |
| Budget, 80% actual ($52.8k) | Around day 22 | ~$8,800 |
| Someone reads the invoice | Day 32+ | $12,000+ |
Same incident, and the gap between row one and row four is about $11,500. That difference is not bought by better ML. It's bought by thresholds someone actually chose.
The four blind spots that survive good thresholds
Honesty section. Even configured exactly as above:
- Nothing here is real time. Billing data lands 8-24 hours behind reality, and both tools evaluate roughly three times a day on top of that lag. (CloudWatch billing alarms don't fix this either; the EstimatedCharges metric updates a few times a day and only sees the total.) Same-hour detection requires usage metrics, not billing data.
- Slow creep still wins against the anomaly detector. That's structural: baselines adapt. The countermeasures are the budget ladder above and a monthly look at unit costs (cost per request, per environment, per team) where creep can't hide inside "normal".
- New workloads are unprotected at first. Anomaly baselines need about ten days of history; forecast alerts need about five weeks. The first month of a new account is exactly when mistakes happen and exactly when both tools are still warming up.
- A service-level anomaly is not an owner. "EC2-Other spiked in account 4412" starts an investigation; it doesn't name the resource, the team, or the cause. That last mile is tags, cost categories, and someone's afternoon.
That fourth gap is the one to take seriously, because time-to-owner is usually longer than time-to-alert. It's also where purpose-built tools go further than the native pair: ZopNight's anomaly reports, for example, run always-on detection at five levels (org, account, resource group, individual resource, and team) against a 7-day rolling baseline, with published severity bands (30-150% above baseline is a warning, 150-500% critical, above 500% emergency, and a z-score of 3+ forces critical regardless), plus a root-cause tag on every flag: instance resize, new deployment, reservation expiry, schedule failure. The point isn't the tool; it's the design bar. A detector should tell you its exact thresholds, and it should hand you a probable cause with the alert, not just a graph.
Alerts are a budget too
You get maybe one interruption a day before a team stops reading cost alerts forever. Spend it like money: one high-bar page that's almost always real, one low-bar digest that's almost always skimmed, one forecast alert that means "act this week", and zero-spend tripwires on the accounts that should stay dark. Every threshold above is a starting point, not a law; the tuning rule is simply that false pages raise the absolute floor, and missed incidents lower the percentage.
FAQ
What is the difference between AWS Cost Anomaly Detection and AWS Budgets?
Budgets compares cumulative spend against a fixed line you set in advance (with actual and forecasted alerts). Cost Anomaly Detection learns each service's normal spend pattern with ML and flags deviations from it, with no fixed line. Budgets catches drift past a limit; anomaly detection catches sudden changes in shape. They cover each other's blind spots, so run both.
What threshold should I set for AWS Cost Anomaly Detection?
Combine an absolute and a percentage threshold with AND: an absolute floor around 5% of your typical daily spend (minimum $50) plus a deviation percentage between 10% and 40%, tighter for larger bills. Example: at $30k/month, alert on impact ≥ $100 AND ≥ 25%. Add a separate daily summary subscription at a quarter of the absolute floor for review-only visibility.
Why didn't AWS Cost Anomaly Detection catch my cost increase?
The usual reasons: the increase was gradual, so the baseline adapted to it (anomaly detection only catches deviations, not trends); the monitor was new and still building its baseline (about ten days); the threshold was absolute-only and the spike sat under it; or the spend sat in a dimension the monitor doesn't segment, like a single account monitor hiding per-service changes.
Can AWS detect cost anomalies in real time?
No. Billing data itself lags 8-24 hours, and evaluations run a few times a day on top of that, so a day is the realistic floor for billing-based detection. For same-hour detection you need usage-level signals (CloudWatch metrics on the resources themselves) rather than cost data.
Do AWS Budgets and Cost Anomaly Detection cost money?
Cost Anomaly Detection is free. Budgets with alerts are free in practice for typical usage; budgets with attached actions bill roughly $0.10 per day each after a small free allowance (pricing as of early 2026, worth confirming on the AWS Budgets pricing page).
Should alerts go to email or Slack?
Page-level alerts belong where the on-call conversation happens: SNS into Slack (via AWS Chatbot) or your incident tool. Digest-level summaries belong in email, where being ignored for a day is acceptable. Splitting the two channels is half of what makes the high-bar alert credible.
Top comments (0)