Cloud cost anomaly detection on AWS and Azure: catch spend spikes before the invoice

Cloud cost anomaly detection is a model that learns the normal shape of your daily spend, builds an expected band around it, and flags any day that falls outside that band. It is not a fixed threshold like a budget, it is a statistical baseline that adapts as your usage grows and dips with the working week. The point is to catch the runaway resource, the misconfigured job, or the forgotten environment in days, not when the invoice lands at the end of the month.

Both major clouds now ship this for free, and the mechanics are similar. Here is how each works, and where the real value lies once a spike has been flagged.

How AWS does it

AWS Cost Anomaly Detection is a free feature inside Cost Management. You define cost monitors that scope what the model watches, by AWS service, by linked account, by cost category, or across the whole organisation, and the model applies machine learning to your daily spend on each. When it detects spend outside the expected band, it raises an anomaly with a root-cause breakdown and an estimated impact. You then attach alert subscriptions that decide who hears about it and when:

• Individual alerts fire per anomaly above a value you set, delivered by email or to an Amazon SNS topic.
• Daily or weekly summaries roll detected anomalies into a digest, so low-noise monitors do not flood inboxes.
• Thresholds can be an absolute amount or a percentage above expected, so a small dev account and a large prod account can use the same monitor with sensible alerting.

How Azure does it

Azure Cost Management splits the same job across a couple of features, all free. Anomaly detection runs automatically in Cost analysis: open the Insights on a subscription and Azure surfaces detected anomalies in your daily spend against its learned baseline, with a breakdown of what drove the change. To be told rather than to go looking, you create a scheduled anomaly alert, which emails named recipients when an anomaly is detected on the scope you choose. Keep two things separate in your head here:

• Anomaly alerts are dynamic. They fire when spend deviates from the model, with no number for you to set.
• Budget alerts are static. They fire when actual or forecast spend crosses a fixed amount you defined, which is a different and complementary control.

Run both. The budget catches the spend you planned to cap; the anomaly model catches the surprise you never thought to set a number for.

Detection is the easy part

Here is the trap. Switch on either tool and you will start receiving alerts, and an alert that nobody owns is just a more anxious version of the invoice. The spike still happened, you just feel worse about it sooner. The value is not in the flag, it is in what happens in the hours after the flag:

1. Attribute it. Tie the anomaly to a named owner, the team or person whose resource, deployment, or job moved the line. The native breakdown tells you the service and account; you still have to land it on a human.
2. Decide accept or fix. Either the spike is legitimate growth, in which case you accept it and move the forecast so it stops alerting, or it is waste, in which case you root-cause it and remediate.
3. Realise the outcome. If it was waste, confirm the spend came back down against the real bill after the change. An anomaly you closed without verifying is an anomaly you might reopen next week.

Spotting the spike is the cloud doing its job. Realising the saving is yours: attribute it to an owner, then accept it or fix it before the band quietly resets around the new, higher normal.

That last risk is the one teams underestimate. Leave an unactioned anomaly long enough and the model relearns, the elevated spend becomes the expected band, and the alert stops firing while you keep paying. Detection without fast attribution and a decision does not save money, it just delays the moment you stop noticing.