AWS Cost Anomaly Detection — the free ML alarm for the spike you never forecast.

IWhat Cost Anomaly Detection actually is — and why a budget can't do its job

Cost Anomaly Detection is a free, native AWS service that uses machine learning to model your normal spend per service and alert you when actual spend deviates beyond the model's expectation. It is the detection layer of FinOps on AWS — the alarm for the costs you never saw coming.

Mechanically, you do two things: create a monitor that scopes what the ML watches, and attach an alert subscription that decides who hears about a detected anomaly and how large it has to be. Behind that, AWS ingests your Cost & Usage data, builds a per-service baseline of expected spend, and continuously compares actual spend against it. When the deviation is large and confident enough, it raises an anomaly record with a start date, an estimated total impact in dollars, the root-cause service / account / usage-type breakdown it can attribute, and a chart of expected-versus-actual.

The service itself costs nothing — no per-monitor fee, no per-alert fee. It runs on the same Cost & Usage data AWS already collects to bill you, so enabling it is pure upside. The only real cost is operational: someone has to read the alerts and act on them, which is exactly the loop a CloudRoute partner can run for you.

Here is why this is a distinct tool and not a feature of Budgets. A budget is a threshold you set: "tell me at 85% of $20K." That works beautifully for spend you can anticipate — but you cannot write a threshold for a surprise. The night a leaked access key spins up a fleet of GPU instances in a region you never use, no budget you would have thought to create catches it; the spend is novel, in a service you do not normally touch, at a scale you never forecast. Anomaly Detection catches it precisely because it does not depend on you predicting it — the model knows that service has historically cost ~$0, so $4,000 of it overnight is, statistically, an obvious anomaly. Budgets enforce the knowns; Anomaly Detection surfaces the unknowns.

The honest boundary: it is not instant. Cost data lands on a lag, so an anomaly is typically surfaced within about 24 hours of the spend beginning — fast enough to stop a multi-day leak from becoming a multi-week one, but not a real-time circuit breaker. It also does not fix anything; it alerts. The fix happens in Cost Explorer (to find the why) and then in the console / IaC (to kill the resource, rotate the key, roll back the deploy). Anomaly Detection's one job is "tell me, fast and with low noise, when spend does something it has never done before."

IISetting up monitors — service, account, Cost Category, and tag

A monitor defines the lens the ML looks through. The lens you choose decides how precisely an anomaly gets attributed — and the single most common mistake is creating one broad monitor and calling it done. Here is what each monitor type watches, and the order a practitioner usually creates them.

IIIAlert subscriptions and thresholds — absolute $, percentage, and ML-confidence

A monitor with no subscription is a model talking to itself. The subscription decides who gets told, how often, and — critically — how big an anomaly has to be before it interrupts a human. Set the threshold too low and you train the team to mute; too high and you miss the slow leak.

An alert subscription attaches to one or more monitors and has three moving parts: a frequency, a threshold expression, and a set of recipients. The threshold is the whole game, and AWS gives you three ways to express it.

IVHow the ML works — and how to tune out false positives

You cannot tune what you do not understand. The model is not magic, and its failure modes are predictable — which means false positives are fixable rather than something you suffer. Here is the mental model, and the levers.

Cost Anomaly Detection builds a statistical baseline of each monitored dimension's spend over time, learning daily and weekly seasonality — weekday-versus-weekend patterns, month-boundary effects, the natural rhythm of your batch jobs. When new spend lands, it compares actual against the predicted range and scores how far outside the expected band it is. A large, confident deviation becomes an anomaly with an estimated dollar impact; small wobbles inside the expected range are ignored. The model also adapts: a one-off spike it flags today becomes part of the learned pattern if it persists, so a genuine, sustained step-up in spend stops alerting once it is the new normal.

Two consequences worth internalising. First, the model needs history — roughly several weeks — to predict well; on a brand-new account, or right after a major architecture change, expect more false positives until it relearns. Second, anomalies are about shape, not amount: a steady $50K/month service that stays steady never alerts, while a $20 service that suddenly costs $200 might — because the second is a deviation from its pattern and the first is not.

• Raise the threshold expression — The first and bluntest lever. If you are getting noise, increase the absolute-dollar floor, the percentage, or both (the AND expression). Most "too many alerts" complaints are solved here in thirty seconds.
• Use Cost Category / tag monitors instead of one giant monitor — A monitor scoped to a coherent business dimension has a cleaner, more predictable baseline than "all spend lumped together," so its anomalies are sharper and its false-positive rate lower.
• Give it time after big changes — A planned migration, a new product launch, or a deliberate scale-up will trip alerts while the model relearns. That is expected — let it absorb the new pattern over a couple of weeks rather than fighting it.
• Don't monitor what you don't care about — If a noisy low-value service keeps firing and you genuinely do not need to watch it, narrow the monitor's scope so the model isn't alerting on spend that has no business consequence.
• Provide feedback on flagged anomalies — Each anomaly can be marked as a real issue or not — this signal helps tune relevance over time and keeps the team's trust in the channel high, because confirmed-false anomalies stop being treated as fires.

VResponding to an anomaly — the triage workflow to root cause and fix

Detection without a response runbook is just a louder way to be surprised by the invoice. The value is in the loop: an alert fires, a human triages it, roots-causes it in Cost Explorer, and fixes the underlying resource. Here is the workflow a practitioner runs, start to finish.

When an individual alert lands, the anomaly record itself already gives you a head start: the start date (when the deviation began), the estimated total impact in dollars, the root-cause attribution AWS could infer (which service, which linked account, which usage type, sometimes which region), and an expected-versus-actual chart. That is usually enough to know whether this is a five-minute fix or a real incident. The disciplined response runs in five steps:

• 1 — Triage: real or expected? — First question: did we cause this on purpose? A planned load test, a launch, a new customer onboarding can all be legitimate. If it is expected, mark it and move on. If not, escalate. Thirty seconds of triage prevents most fire drills.
• 2 — Read the attribution on the anomaly itself — The record names the service, account, and usage type driving the impact. "EC2 / prod-data / BoxUsage:p4d.24xlarge in us-west-2" tells you almost everything: GPU instances in a region you don't use — likely a leaked key or a runaway job.
• 3 — Root-cause in Cost Explorer — Open Cost Explorer filtered to the anomaly's service and date range, then group by usage type, then by linked account, then by tag. This is where "EC2 went up" becomes "an unbounded auto-scaling group launched 60 c5.4xlarge after the 14:00 deploy." Cost Explorer is the microscope behind the alarm.
• 4 — Fix the underlying resource — Now act on the actual cause: stop / terminate the runaway resource, rotate and quarantine a leaked credential, roll back the deploy, right-size the over-provisioned cluster, or add the missing NAT/VPC-endpoint to kill the cross-AZ egress. The fix lives in the console or your IaC, not in the anomaly tool.
• 5 — Prevent the recurrence — Close the loop so it cannot happen the same way twice: a Budget Action to auto-stop tagged non-prod resources at a cap, an SCP guardrail on the offending region, tighter IAM on instance launches, or a tag rule so the next occurrence is at least attributable. Detection finds it once; prevention stops the repeat.

VICost Anomaly Detection vs Budgets vs Cost Explorer — when each one

These three native tools get constantly confused, and teams waste effort forcing one to do another's job. They are complementary layers of a single practice, not competitors. Here is the clean mental model, with the full comparison table below.

Cost Anomaly Detection answers "did something just change that I did not predict?" A free ML monitor that learns each dimension's normal pattern and alerts on significant deviations — the unknown-unknowns, because you cannot set a threshold for a surprise. Best for a misconfigured service, a leaked key, or a deploy that 10×'d data transfer overnight. It detects; it does not enforce or explain.

AWS Budgets answers "are we on track against a number I set, and what should happen if we are not?" Proactive and threshold-driven — you define the target, Budgets enforces it and can even act on breach via Budget Actions (apply an SCP/IAM policy, stop EC2/RDS). Best for monthly cost caps, commitment-utilization floors, per-team guardrails, and automated stops on non-prod. It enforces the knowns; it cannot catch the spike you never forecast.

Cost Explorer answers "why did this number move, and where is the money going?" The investigation tool — interactive charts, group-by service / account / usage-type / tag, historical trends, plus where you build forecasts and RI/SP recommendations. It does not alert and it does not enforce. Best for root-causing an alert, planning commitments, and reporting. Anomaly Detection or a Budgets alert tells you something is wrong; Cost Explorer is where you find out why.

VIIIntegrating with Slack and PagerDuty via SNS

An anomaly alert that lands in an inbox nobody watches is a detection system that fails silently. The value is in routing the signal to where the team already lives — and where it can page someone if it has to. Both flow through Amazon SNS.

Cost Anomaly Detection alert subscriptions can send to email directly, or — far more powerfully — to an Amazon SNS topic. SNS is the fan-out hub: one anomaly alert can simultaneously hit email subscribers, a Lambda function, an SQS queue, and chat / paging integrations. You must grant the Cost Anomaly Detection service principal permission to publish to the topic — a small SNS resource (access) policy that is the one step people miss, after which alerts flow.

For Slack, two clean patterns. Simplest is AWS Chatbot (now part of Amazon Q Developer): subscribe it to the anomaly SNS topic, authorize your Slack workspace and channel, and anomalies render as formatted messages with no code to maintain. More flexible is SNS → Lambda → Slack incoming webhook, where a small function reshapes the alert into a rich message (service, account, dollar impact, a direct Cost Explorer deep-link to the affected service + date range) and posts to a channel webhook — so the responder can start step 3 of the triage workflow in one click.

For PagerDuty (or Opsgenie), wire the same SNS topic to the provider's AWS/SNS integration so a material anomaly creates an incident and pages on-call — appropriate for the leaked-key class of event where a 2am $4K spike genuinely warrants waking someone. The usual split: route everything to a #finops Slack channel for visibility, but only page PagerDuty for anomalies above a higher dollar threshold, so on-call is woken for real fires, not the long tail.

Route both Cost Anomaly Detection and AWS Budgets alerts to that same #finops channel via SNS, so every spend signal — the surprises and the thresholds you set — lives in one place. That single channel is the heartbeat of a working FinOps practice.

VIIICost Anomaly Detection best practices that actually move the needle

A detection setup either becomes a trusted alarm the team acts on, or noise everyone mutes by week two — and muted detection is worse than none, because it gives false confidence. The difference is a handful of deliberate choices; these are the practices CloudRoute partners apply, ranked by impact.

• Turn it on day one — it's free — There is no pricing reason to wait. Create at minimum one AWS-services monitor covering the whole account / Organization, with one individual-alert subscription. The most expensive surprises hit accounts that never enabled the one free tool built to catch them.
• Use a combined $-AND-% threshold — The single biggest false-positive killer: alert only when impact is both above an absolute dollar floor AND above a percentage of expected. That one expression eliminates the trivial-dollar / huge-percent and large-dollar / tiny-percent noise that trains teams to mute the channel.
• Scope monitors to how the business thinks — Layer a services monitor (always-on) with account, Cost Category, and tag monitors so anomalies are pre-attributed to a team / environment / product. Scoped monitors have cleaner baselines and sharper, lower-noise alerts than one giant lump.
• Write the response runbook, not just the alert — Detection without a triage-to-root-cause-to-fix loop is just louder surprise. Document the five steps (triage → read attribution → root-cause in Cost Explorer → fix the resource → prevent recurrence) so an alert produces an action, not a shrug.
• One channel for all spend signals — Fan Anomaly Detection and Budgets alerts into the same #finops Slack channel via SNS, and page PagerDuty only above a higher dollar bar. Signals scattered across inboxes get ignored; one watched channel becomes the FinOps heartbeat.
• Close every anomaly with a guardrail — After a real anomaly, add the prevention — a Budget Action to auto-stop non-prod, an SCP on the offending region, tighter launch IAM, or a tag rule. Detection finds it once; the guardrail stops the same mistake twice.
• Tag first, then trust tag monitors — Per-tag (and per-team) detection is only as good as your Cost Allocation Tags. Activate and enforce tags before relying on tag monitors, or untagged spend becomes a blind spot — the exact place stealth cost hides.
• Expect noise after big changes, and let it learn — A migration, launch, or deliberate scale-up will trip alerts while the model relearns the new normal. Don't rip the monitor out — give it a couple of weeks to absorb the pattern, and the false positives subside on their own.