AWS Budgets vs Cost Anomaly Detection (2026)

Both of these watch your bill and email you. They are not alternatives, they fail in different directions, and there is one category of charge that only one of them sees at all. Running just one leaves a real gap.

What is AWS Budgets?

A threshold you set yourself. Per Managing your costs with AWS Budgets, you can alert on "both actual (after accruing) and forecasted (before accruing) spends", which is the part worth internalising: a forecasted alert can fire before the money is spent.

Six budget types are documented, and only the first two are about spend:

The utilization and coverage budgets are the underused ones. They catch a commitment you bought and stopped using, which is a silent loss that no cost threshold will ever trip, because the spend looks normal.

Budgets are also explicit about which cost basis they use, which matters given how easily unblended and amortized numbers get compared to each other: they "can track your blended, unblended, net unblended, amortized, and net amortized costs" and "can include or exclude charges such as discounts, refunds, support fees, and taxes."

What is AWS Cost Anomaly Detection?

A model that learns your normal and tells you when you deviate from it. Per Detecting unusual spend with AWS Cost Anomaly Detection, it "uses machine learning models to detect and alert on anomalous spend patterns", evaluating "weekly or monthly seasonality and natural growth" so that expected variation does not page you.

The difference from a budget is the one that matters. A budget knows only the number you gave it. Anomaly detection has no number: it knows what you usually spend. So it catches a service that quintuples while your total stays under budget, which is the failure a threshold structurally cannot see.

It also attributes. Anomalies are split "across four dimensions: AWS service, AWS account, Region, or usage type", with root causes ranked by dollar impact. Cost impact is defined as actual spend - expected spend, and impact percentage as (total cost impact / expected spend) * 100.

One counter-intuitive detail in how it ranks severity: "a small spike with historically consistent spend is categorized as high severity. And, similarly, a big spike with irregular historical spend is categorized as low severity." Severity is about how abnormal the spike is, not how large. A steady workload moving slightly is a bigger signal than a noisy one moving a lot.

How fast does each one alert?

Neither is real time, and the documented lags are different.

AWS states the anomaly consequence plainly: "it can take up to 24 hours to detect an anomaly after a usage occurs." A runaway resource started on Monday morning may not surface until Tuesday morning.

Budgets carry their own warning, and it is worth quoting because it kills the idea of a budget as a spending cap: "you might incur additional costs or usage that exceed your budget notification threshold before AWS Budgets can notify you, and your actual costs or usage may continue to increase or decrease after you receive the notification." A budget notifies. It does not stop anything by itself.

That last point has an exception worth knowing, and it is bigger than a notification. Per Configuring budget actions, you can "run an action on your behalf when a budget exceeds a certain cost or usage threshold", and crucially you choose whether it runs "either automatically or after your manual approval". Manual approval is what makes this usable in production: the action is staged and waits for a human.

Three action types are documented, not one:

You can also "configure multiple actions to initiate at the same notification threshold". One documented cross-account limit: from the management account "you can apply an SCP to another account. However, you can't target Amazon EC2 or Amazon RDS instances in another account."

This is the only mechanism in either service that actually intervenes rather than informs. Start it on manual approval.

What does Cost Anomaly Detection not see?

The gap that decides whether you need both:

"Cost Anomaly Detection does not monitor third-party products and services available through AWS Marketplace, except for third-party foundation models on Amazon Bedrock… To get alerts for other AWS Marketplace charges, use AWS Budgets."

AWS is naming the remedy in its own documentation. If you buy anything through Marketplace, and most organisations of any size do, anomaly detection is blind to it and a cost budget with a Billing entity filter is the documented answer.

The Bedrock carve-out is a genuine oddity in the right direction: third-party foundation models bill under the AWS Marketplace billing entity but are monitored. So an unexpected spike in third-party model inference is caught, while an unexpected spike in a Marketplace security appliance is not. If you are working on attributing Bedrock spend, that distinction is worth knowing before you assume coverage.

Two more limits, both easy to trip over in an organisation:

• "Cost monitors for linked accounts, cost allocation tags, and cost categories can only be created in the management account", and monitors are only accessible "under the account that created them".
• "Cost Anomaly Detection isn't available for bill source accounts that use billing transfer."

Which monitor type should you use?

Two flavours, and the choice is about coverage versus control. Per Getting started with AWS Cost Anomaly Detection, AWS managed monitors "automatically track the top 5,000 values independently within a dimension"; customer managed monitors "let you select specific values that get monitored in aggregate", capped at 10.

Note "in aggregate" for the customer-managed case. Selecting ten accounts monitors their combined spend, so one account doubling while another halves can cancel out and never alert. AWS managed monitors evaluate each value independently, which is what most people assume they are getting.

The 5,000 ceiling has a documented spillover: "if your organization has more than 5,000 values… the monitor will track the top 5,000 values based on their total spend." Small accounts and rarely-used tag values fall off the bottom, which is precisely where an unnoticed anomaly likes to live.

Tag and cost category monitors are the ones that map to team ownership, and both inherit their upstream problems: a tag monitor is only as good as your tag coverage, covered in why cost allocation tags show up empty, and a cost category monitor inherits whatever your rules say, covered in what split charge rules can and can't do.

Is AWS Budgets free?

One charge is documented precisely, and it is not the one people mean. AWS AWS Budgets Reports, the scheduled digest of your existing budgets, cost "$.01 USD for each report delivered. This is regardless of the number of recipients receiving the report", with a limit of 50 reports per standalone or management account and up to 50 email addresses each.

For whether budgets and Cost Anomaly Detection themselves carry a charge, read the AWS Cost Management pricing page rather than this post. Neither service's documentation states a price, and we do not publish rates we cannot source.

What the docs do settle is that Cost Anomaly Detection does nothing until you configure it: it "requires setting up at least one cost monitor to define what spending patterns to track". Opting out is the mirror image, and it is worth knowing it is not a switch: "to opt out, you need to delete all cost monitors and alert subscriptions in your account", through the console or through DeleteAnomalyMonitor and DeleteAnomalySubscription. So an account with no monitors is getting no anomaly detection at all, however long it has been open.

How should you set the alerts up?

Anomaly alert subscriptions take "absolute" or "percentage" thresholds, and two can be combined with AND or OR. That combination is the useful part: a percentage threshold alone screams about a $3 service tripling, and an absolute threshold alone misses a small service going badly wrong. Requiring both filters to genuinely significant events.

Alert frequency has a trap in the middle option:

• Individual alerts fire "as soon as an anomaly is detected" and require an SNS topic.
• Daily summaries send the "top 10 alerts from the previous day", generated at 00:00 UTC. AWS's own example: "an anomaly detected at 04:30 UTC on January 14 will be included in the daily summary sent at 00:00 UTC on January 15." That is nearly 20 hours on top of the detection lag, and AWS explicitly says "for immediate alerts, we recommend using the individual alerts option."
• Weekly summaries are for reporting, not response.

A useful reassurance: sub-threshold anomalies are not discarded. "Even if an anomaly is below the alert threshold, the machine learning model continues to detect spend anomalies on your account", and all of them appear in the Detected anomalies tab. Set the threshold for what should wake someone, then review the rest weekly.

What should you actually run?

1. An AWS managed services monitor, for independent evaluation of every service, including ones you have not adopted yet.
2. A cost budget covering total spend, with forecasted alerts, to catch the drift a per-service model treats as normal growth.
3. A cost budget filtered to the Billing entity for AWS Marketplace, because anomaly detection cannot see it.
4. Savings Plans and RI utilization budgets, since unused commitment is invisible to both a cost threshold and an anomaly model.
5. Individual alerts, not daily summaries, for anything meant to prompt a response.

And keep the expectations honest. Both tools tell you after the money is spent, by up to a day. They reduce the size of a surprise; they do not prevent one. The only documented mechanism here that stops spend is a budget action, and that is a decision to make deliberately, on manual approval first, rather than a default to switch on.