A cost anomaly is a movement that the scope's own history makes unlikely: a jump, a drop, or a charge that did not exist the day before. It matters for the bill because the cloud charges for usage as it happens and nobody approves an amount before it is incurred: a forgotten load test or a deployment with the wrong instance size runs until month end unless something reports it. The anomaly is the earliest signal billing data can give, and a cost insight that asks a question before the report answers it.

How it works

Every detector needs a scope, an expectation and a threshold. The scope is the unit whose history is watched: a service, an account, a tag value, a usage type. The expectation is what that scope's history makes likely for the day, with seasonality by weekday and month and natural growth factored in, so a Monday after a quiet weekend does not alert. The threshold sets the deviation at which a detection becomes a notification: absolute in currency, relative in percent, or both, with a minimum amount so a service with a negligible daily cost does not alert when it doubles.

The scope decides more than the model does. A total smooths what a single service shows: when a small service grows several times over, the account total moves by a fraction of that and stays inside its usual variation. That is why the providers' detectors watch per service, account or tag value, not the sum alone.

AWS

AWS Cost Anomaly Detection works with monitors and alert subscriptions. A monitor watches one dimension: AWS services, linked accounts, a cost allocation tag or a cost category. AWS managed monitors evaluate every value of the dimension on its own and pick up new accounts or tag values automatically; customer managed monitors aggregate up to ten values you select. A subscription sets the recipients, the frequency (individual alerts through Amazon SNS, daily or weekly summaries by email) and the threshold: an absolute amount, a percentage of expected spend, or both. For each anomaly AWS ranks the likely root causes by service, account, region and usage type. The cost basis is net unblended cost, after discounts. Detection runs about three times a day on Cost Explorer data that lags by up to 24 hours; a new monitor needs 24 hours and a newly used service ten days of history.

Azure

Azure Cost Management evaluates anomalies at subscription scope, once a day. The day's total is compared with a forecast built from the previous 60 days, which accounts for recurring patterns such as a busy Monday; the run happens 36 hours after the end of the day (UTC) so the data set is complete. The result shows as an insight in the smart views of cost analysis. An anomaly alert is an alert rule of type Anomaly, available only at subscription scope and limited to five per subscription; the email is sent once, at detection, and summarises the change by resource group against the previous 60 days. Azure distinguishes new, removed and changed costs; a resize, for example, surfaces as a new meter replacing a removed one under the same resource.

Google Cloud

Google Cloud Billing detects anomalies on the billing account across its linked projects. The documentation describes them as spikes or deviations from historical spending patterns; a cost impact threshold and a deviation percentage are set automatically from usage patterns, and a billing account administrator can change them. The cost basis is gross cost at on-demand rates, including spend-based committed use discounts but excluding credits and sustained use discounts. Notifications go by email, per anomaly or as a daily summary, or through Pub/Sub, and the settings apply to every project on the account. For each anomaly Google names the top contributors by service, region and SKU. Standard anomalies arrive through next-day channels; only the Gemini API and Vertex AI, which Google now names Gemini Enterprise Agent Platform, have early anomalies in preview, built on estimates that do not appear in the cost reports.

What it means for your cost

An anomaly is a question, not a finding. It says a scope behaves differently from its history, not that something is wrong: a new product or a migration draws the same curve as a forgotten cluster. Only the scope's owner knows the answer, so an anomaly is closed once its owner has recorded a cause and decided whether the cost stays. That is also why detection should run on a scope with an owner, an account, a tag or a cost category, not on the service alone.

The anomaly never appears on the invoice as a line of its own. It is the part of a usage line that exceeded the expectation, reported as cost impact: actual minus expected spend over the anomaly's duration. In between sits the lag: usage happens, is metered hours later, reaches the cost data after up to a day and is evaluated in the next run. A day is the normal lag, sometimes more, so what the detector reports has been running for at least a day, and what it reports as ended has been over for a day.

In a cost report the anomaly is an outlier in the scope's daily series, not in the monthly total. The cost basis decides what stands out: AWS evaluates cost after discounts, Google gross cost without credits, so an expiring credit is an increase in one and invisible in the other. FinOps treats detection as a capability of its own, Anomaly Management, in the Understand Usage & Cost domain of the FinOps Foundation's FinOps Framework.

Where it goes wrong

  • Detection on the total only. The monitor watches the whole account, and one service grows fivefold without the total leaving its usual variation. Nothing unusual happened in the scope being watched, so nothing is reported.
  • Thresholds at which every deploy alerts. A percentage threshold without a minimum amount reports the doubling of a service that costs almost nothing; recipients learn to ignore the emails and miss the one that matters.
  • Nobody subscribed. The monitor exists, but the subscription has no valid recipient, or the permission behind it is gone; Azure sends only while the rule's creator still has read access. The anomalies sit in a list nobody opens.
  • Closed without a cause. The anomaly is marked as known because the increase has passed. Without a recorded cause the same mistake repeats next month.
  • A commitment purchase or a credit read as an anomaly. A reservation purchase shows as a one-day jump, an expiring credit as a rise in net cost at unchanged usage. Both are rate effects, not usage changes, and belong in period comparison.
  • Detection expected to replace a budget. An anomaly reports deviation from history. Steady growth of a few percent a month is never anomalous and still overruns the budget; a budget alert checks against an amount, not the past.

Sources

Read on 2026-10-15. AWS Cost Anomaly Detection and monitors and alert subscriptions; Microsoft identify anomalies and unexpected changes in cost; Google Cloud cost anomalies; FinOps Foundation FinOps Framework.