The monthly invoice is the worst place to find a cost problem. By the time a spike reaches the bill, it has usually been running for weeks, and the total that finance reviews rolls dozens of services into a single number that moves too slowly to reveal what changed underneath it.
Consider a service that jumps 28% week-over-week. On a $945 base, that’s an extra $265: real money, and often the leading edge of a trend that compounds. But $265 against a five- or six-figure cloud bill doesn’t move the total enough to notice. Nobody reads the invoice and thinks “data transfer is up 28%.” You’d never catch it by hand. That’s precisely the kind of movement a detection system exists to surface.
The interesting design question isn’t whether to detect anomalies; it’s that no single detection method catches everything. So CostDefender runs two.
Two detection engines, not one
The two methods are good at different things, and that’s the point of running both.
AWS Cost Anomaly Detection is a machine-learning service that builds a model of what each monitored service should cost on a given day, then flags days where actual spend breaks out of that expected band. It’s excellent at catching sharp, obvious deviations like the sudden 2.8× spike, and it comes with AWS’s own root-cause attribution. CostDefender reads these back over a trailing 30-day window and surfaces them with the impact, the expected figure, and the actual figure attached.
Week-over-week analysis is CostDefender’s own, deliberately simple second net. It pulls the last 14 days of daily spend grouped by service, sums it into two seven-day windows, and compares them. An alert fires only when a service is both more than 30% up and more than $50 higher than the prior week, two gates that filter out the noise of tiny services doubling on a rounding error.
Why both? An ML model tuned to avoid false positives will tolerate a steady, structural drift: a workload quietly growing 30% a week for a month barely registers as “anomalous” because each day looks like a reasonable continuation of the last. Week-over-week comparison catches exactly that creep. Meanwhile the ML model catches the abrupt spikes that a seven-day average would blend away. When a service trips both, the anomaly model’s alert wins the dedupe, and everything is ranked by dollar impact.
What the alert feed actually shows
Here’s a representative week of alerts, the kind of feed the two engines produce together:
Read that feed as a finance leader and the value is immediate. The Bedrock spike is loud: 2.8× expected, flagged high, worth investigating today. But the one that earns its keep is the data-transfer alert at the bottom. A 28% rise worth $265 is invisible on the invoice and beneath the threshold of anyone’s attention until it’s a pattern. Surfacing it now is the difference between a five-minute look at cross-region traffic and a surprise on next quarter’s bill.
Severity is measured in dollars, not percentages
Notice what ranks the feed: dollar impact, not percentage change. This matters more than it first appears.
A percentage-first system floods you with noise: a $5 test service tripling to $15 is a 200% “anomaly” that means nothing. CostDefender buckets severity by the actual dollars at stake: an impact of $1,000 or more is High, $200 or more is Medium, and anything smaller is Low. That’s why a 34% RDS increase ($924) and a 2.8× Bedrock spike ($1,140) land near each other despite very different percentages: they’re comparable amounts of money. Prioritizing by dollars keeps the feed aligned with the only question that matters at review time: where is the money actually moving?
From alert to accountable action
An alert is a signal, not a resolution. The Bedrock spike above is a good example: a sharp, unexplained increase in inference cost with no matching deployment is exactly the kind of thing that deserves a name next to it, not just a red badge. So a high-impact anomaly becomes an assignable recommendation:
From there it follows the same lifecycle as any recommendation: assign an owner, mark it in progress, and, once the change is made, verify the realized savings against the actual bill. If an operator determines the spend is legitimate and expected, they dismiss it with a note, and it moves out of the active list. The anomaly doesn’t just get noticed; it gets closed.
Why this runs on read-only access
Everything above happens through Cost Explorer reads on a role that can look but never touch. There are no agents to install, no write permissions to grant, and nothing in the pipeline that can change your infrastructure. Detection is a data problem, and the data, daily spend per service with AWS’s own anomaly model layered on top, is already there. The work is in surfacing it in a form finance can act on, ranked by the dollars at stake, before it reaches an invoice where it’s too late and too blended to see.
The best time to learn that data transfer is up 28% is the week it happens. Not the quarter it shows up in the total.
CostDefender connects to your AWS environment with read-only access and surfaces cost anomalies with the severity, context, and ownership your team needs to act before the next bill. See how it works →