Diagnostics — 10 min read

Why did my AWS bill suddenly go up?

A sudden jump is easier to diagnose than general overspend — you have a control group, and the change has a name.

By Plainstack/August 14, 2026

A bill that climbs 5% a month is a budgeting problem. A bill that jumps 40% in one month is a question, and it usually has one specific answer rather than twenty diffuse ones.

The good news is that sudden increases are far easier to diagnose than general overspend, because you have a control group: last month. Something changed, the change has a name, and the billing data will tell you what it is if you ask it correctly.

Step one: ask the right question in Cost Explorer

Almost everyone opens Cost Explorer, groups by Service, and compares two months. That tells you where the money went — EC2, RDS, S3 — which you could have guessed. It doesn't tell you what changed.

Group by Usage Type instead. Now the delta reads like a diagnosis:

BoxUsage:m5.2xlarge up 300% — instances were added, or scaled and never came back
NatGateway-Bytes up 400% — something new is pushing traffic through NAT
TimedStorage-ByteHrs up steadily — storage accumulating, not a step change
DataTransfer-Out-Bytes up — you're serving more, or serving it the expensive way
A commitment line that disappeared — read on, this one catches people out

Set the date range to cover both months, granularity to daily, and filter to the one or two usage types that dominate the delta. Daily granularity matters, because the shape of the increase tells you what kind of problem it is.

Step two: is it a step or a slope?

This is the single most useful distinction, and it takes one glance at a daily chart.

Decide

On a daily chart, how does the increase look?

A cliffCost jumps on one specific day and stays flat at the new level. Something was switched on, scaled up, or expired on that date. Find the date, then find what changed that day — a deploy, a launch, an incident, or a commitment ending.

A rampCost climbs steadily. This is accumulation — storage, snapshots, logs, or organic growth in traffic. Nothing 'happened'; something has simply never been cleaned up or has outgrown its configuration.

A spike that came back downA one-off — a migration, a backfill, a load test. Worth understanding so it doesn't recur unplanned, but it isn't a standing cost problem.

Sawtooth, weeklySomething scales with your working week. Usually fine — but check that non-production actually scales down at night rather than just being quieter.

A cliff has a cause you can name and usually undo in an afternoon. A ramp needs a policy rather than a fix, because whatever caused it will keep causing it.

The causes, in the order they're usually the answer

1. Something scaled up and never scaled back

The most common answer by a distance. An autoscaling group hit a ceiling during a traffic event and the new desired-capacity stuck. Someone bumped an instance class to get through an incident at 2am and nobody reverted it. A load test ran against production-sized infrastructure and the cluster was left warm.

Check the instance counts and sizes on the day of the cliff, not today.

2. A commitment quietly expired

This one is worth knowing about because nothing warns you, and it produces a textbook cliff.

Savings Plans and Reserved Instances run for exactly one or three years and then simply stop. Your usage doesn't change at all, but everything that was covered by that commitment reverts to on-demand rates overnight. A bill can jump 20–30% without a single resource changing.

If your increase is a cliff and you can't find any infrastructure change on that date, check whether a commitment ended that day. Then see the commitments guide for how to size the replacement — and put the new expiry date in a shared calendar immediately, because this will otherwise happen again in twelve months.

3. A new integration is pushing traffic through NAT

A new third-party service, a data pipeline, a log shipper, a backup job to S3 — anything that started moving real volume out of a private subnet gets billed twice, once for NAT processing and once for transfer. NatGateway-Bytes is the usage type to check, and the fix is often free. The NAT Gateway guide covers it properly.

4. Storage crossed a threshold

Storage is the classic ramp. Snapshots accumulate, CloudWatch log groups never expire, S3 versioning keeps every overwrite, EBS volumes are provisioned for growth that already happened.

It rarely feels sudden from the inside, but it can look sudden if you only check the bill quarterly. If the shape is a ramp and the usage types are TimedStorage or SnapshotUsage, this is you.

5. GPU and AI workloads left running

Newer, and increasingly the answer. Accelerated instances cost multiples of general-purpose ones, so an idle GPU fleet burns money at a rate that makes ordinary waste look trivial — industry data now puts GPUs at roughly 18% of spend at AI-forward organisations, with statically provisioned fleets running at only 30–40% utilisation.

The pattern is almost always the same: someone provisions a GPU instance for an experiment, the experiment ends, the instance doesn't. Check for accelerated instance families in the usage-type breakdown, and check whether anything is actually running on them.

6. The free tier ended

If the account is around twelve months old, some of the increase is simply the free tier expiring. This is not a problem to solve — it's a bill you were always going to have — but it's worth identifying so you don't go hunting for a cause that doesn't exist.

7. Someone spun up a new environment or account

A new staging environment, a demo account for a customer, a data-science sandbox. Check whether the increase is concentrated in a linked account or a region you don't usually use. An unfamiliar region in the breakdown is worth a look on its own — it's occasionally the first sign of credentials being misused, and it costs nothing to rule out.

What to do in the first hour

Cost Explorer, both months, group by usage type, daily granularity.
Identify the top two or three usage types by absolute dollar increase.
Note the shape — cliff, ramp, spike.
If it's a cliff, find the date, then look at what shipped or expired that day.
If it's a ramp, look at storage and retention policies rather than at events.
Write down what you find, even if you can't fix it today. Next time, the note is worth more than the fix.

Making the next one not a surprise

The real failure here isn't that the bill went up. It's that you found out weeks later, from an invoice.

AWS Budgets with an alert at a threshold you'd actually want to know about. Free, takes five minutes, and almost nobody sets it up until after the first surprise.
Cost Anomaly Detection — AWS's own service, also free. It watches for exactly this pattern and emails you when spend deviates from its baseline, usually within a day or two rather than at month end.
Calendar reminders for every commitment expiry, set on the day you buy.
A monthly ten-minute look at the same usage-type view. Ten minutes a month makes the next jump obvious in days instead of weeks.

If you'd rather see the whole picture rather than just this month's delta, the free teardown reads a Cost Explorer export in your browser and flags the standing patterns underneath the spike — the things that were expensive before this month and will still be expensive after you've fixed it.

Check your own account

Does this apply to you? Find out in two seconds.

Drop a Cost Explorer export into the free teardown. It reads your service mix and tells you which of these patterns show up in your bill — in your browser, with no upload and no email.

Run the free teardown →Book a free call