AWS Cost Anomaly Detection Fired. Now What?

23-05-2026 / Cost optimization strategies / 6 mins.

You set up AWS Cost Anomaly Detection, configured your alert thresholds, and one morning an email arrives: anomaly detected on EC2 spend, 40% above baseline. Great — the monitoring worked. Now you have to figure out what actually happened.

This post covers how to investigate an anomaly alert quickly, the most common root causes, and — more importantly — why most teams are solving the wrong problem when they focus only on the spike and ignore the baseline underneath it.

What anomaly detection tells you (and what it doesn't)

AWS Cost Anomaly Detection uses ML to flag spend patterns that deviate significantly from your historical baseline. When an alert fires, it tells you:

• Which service or account triggered the anomaly.
• Expected vs. actual spend for the period.
• The top contributing usage type — usually something like "EC2 running hours, us-east-1, m5.large."

What it doesn't tell you: who launched what, whether it was intentional, or how to fix it. That part is still manual.

Investigating an anomaly: a quick checklist

1. Open Cost Explorer and filter to the flagged service and time window. Look at the usage type breakdown — find the specific resource driving the increase.
2. Check CloudTrail for resource creation events in the anomaly window — RunInstances, CreateDBInstance, CreateNatGateway.
3. Check CloudWatch metrics on the specific resource. Is utilization spiking or is this just more instances running?
4. Look for orphaned resources — after you fix the root cause, check whether anything was left running that shouldn't be.

The three most common root causes

Intentional activity you forgot to account for

A new deployment, a data migration, a batch job that ran longer than expected. These are anomalies in the statistical sense but not problems. Verify with your team and dismiss the alert.

Runaway processes or misconfigurations

An autoscaling group without a proper max limit, an infinite retry loop, test infrastructure that was never torn down. CloudTrail will usually point you at the culprit within a few minutes.

On-demand pricing on workloads that should be committed

This is the most common root cause that nobody talks about. Your baseline spend is already high because you're paying on-demand rates for workloads that run 24/7. An anomaly fires when you go even higher than that inflated baseline.

If your EC2 bill is ,000/month on-demand and the anomaly fires when it hits ,000 — the alert did its job. But the underlying issue is that the ,000 baseline could be ,000–7,000 with Reserved Instances or Savings Plans. Anomaly detection doesn't address that gap. It just makes the overspend more visible.

Monitoring vs. optimization: a real distinction

AWS Cost Anomaly Detection is a monitoring tool. It tells you when something changed. It is not an optimization tool — it doesn't reduce your bill.

For most companies spending ,000–,000/month on AWS:

• Anomaly detection catches runaway spend — worth maybe ,000–3,000/year in prevented incidents.
• Reserved Instances and Savings Plans reduce the baseline — worth ,000–,000+/year depending on spend level.

Both matter. But one of those is usually an order of magnitude larger than the other.

Lowering the baseline: where Frust comes in

Frust focuses on the part anomaly detection doesn't touch: your baseline on-demand spend on steady-state workloads. Frust connects to your AWS account read-only, identifies which Reserved Instances and Savings Plans fit your usage patterns, and purchases them on its own accounts — passing the discount to you. No 1-year commitment, no upfront payment, no instance changes.

A lower baseline also makes anomaly detection more effective: spikes stand out more sharply against a tighter cost floor.

The model: Frust charges 20% of the savings it generates. If it doesn't save you money, you pay nothing.

Get a free savings estimate — connect your account and get a concrete projection within 48 hours.