The bill arrives, it is roughly double, and nobody on the team can say why. The instinct is to start turning things off. Resist that for two hours and work the problem in order instead, because the most expensive version of this incident is the one where you delete something load-bearing and now have two problems.
This is the order we work it. It is deliberately boring, and it is arranged so the cheapest checks come first.
First, decide whether this is even an incident
A surprising share of sudden doubles are not incidents at all. Rule these out before you open a single console, because each takes under a minute and each fully explains a step change.
| Check | Why it doubles the bill |
|---|
| A Savings Plan or Reserved Instance expired | The same workload silently reprices to on-demand. Nothing changed in your infrastructure, so nothing looks wrong in it. |
| Free tier ended | Twelve months after account creation, a set of services begins billing at once. Common for startups hitting month thirteen. |
| Credits ran out | Activate, accelerator and startup-programme credits mask real spend until the day they do not. |
| Billing period length | A 31-day month against a 28-day month is a adds roughly 10 percent, which is not a double but does distort a quick comparison. |
| Currency | If you read the bill in INR and it is charged in USD, part of the move can be the exchange rate rather than the workload. |
The general form of this check: separate a price change from a usage change. In Cost Explorer, look at usage quantity rather than cost. If the quantity is flat and the cost moved, you have a pricing event, and no amount of hunting through resources will find it.
Second, find the shape of the change
Set Cost Explorer to daily granularity across the last sixty days, then group by service. You are not looking for the biggest service. You are looking for the shape, and there are only three.
A step. The cost jumps on one day and stays flat at the new level. Something was created or switched on. Look at what changed on that date: a deploy, a new environment, a region enabled, a feature flag.
A ramp. The cost climbs steadily. Something is accumulating rather than running. Storage that is never expired, snapshots that are never deleted, log retention set to forever, a table that only grows.
A spike. The cost jumps and comes back down. A one-off job, a backfill, a data migration, a retry storm, or a load test somebody forgot to mention.
The shape tells you which question to ask next, and it usually eliminates two thirds of the surface area.
Third, group by usage type, not by service
This is the step most teams skip, and it is the one that usually finds it. "EC2" being up tells you almost nothing. Grouping by usage type tells you whether it is instance hours, EBS volumes, snapshots, or data transfer, and those are completely different problems with completely different fixes.
The causes we see most often for a sudden double, roughly in order of how frequently they turn out to be the answer:
Data transfer and NAT gateway processing. NAT gateways bill per hour and again per gigabyte processed. A service that starts pulling large objects through the NAT, or a chatty workload moved into a private subnet, produces a large bill with no new resources visible anywhere. Cross-availability-zone traffic does the same thing quietly.
Logging volume. Someone raises a log level to debug during an investigation and it never goes back. Ingestion is usually the expensive half, not storage, so the bill moves the same day.
Storage that is never expired. S3 without lifecycle rules, EBS snapshots without a retention policy, and old volumes left attached to nothing. This is the classic ramp shape.
An environment nobody owns. A staging or demo stack spun up for one client conversation, still running months later. Cheap per hour, expensive per quarter.
A retry storm. A failing dependency plus aggressive retries multiplies requests, and request-priced services (S3, DynamoDB, Lambda invocations, API Gateway) bill for every one of them.
What not to do
Do not delete anything you cannot explain, and do not resize production on the day you found the bill. The cost of an outage is almost always larger than the cost of one more month of the anomaly. Tag what you suspect, confirm the mechanism, then act.
Do not accept "we will just watch it next month" as the resolution either. A cause you did not identify is a cause that is still running.
Making the next one boring
The reason this incident is stressful is not that the bill moved. It is that nobody could answer the question quickly. Three things fix that, in increasing order of effort.
Turn on a cost anomaly alert so the bill tells you rather than you discovering it at invoice time. Establish a tagging convention so cost can be attributed to a team, environment or customer, because an untagged bill can never be explained quickly. And write down the shape of a normal month, so "double" is a statement about a baseline rather than a feeling.
If you want the longer version of the detection piece, we wrote up a free anomaly-detection pipeline using Cloud Custodian and Lambda. For steady-state reduction rather than incident triage, the cost optimization guide is the better starting point. And Ghost-hunter is the open-source tool we built to do the reasoning in this runbook against a billing export, read-only, without touching your cloud.
If nobody has time to run this
That is the honest situation for most early teams, and it is worth saying plainly: this runbook takes a couple of focused hours from someone who has seen cloud bills before. If that person does not exist on your team, a fractional engagement is one way to borrow them, and a 20-minute review is enough to tell you whether your spike is one of the boring five above or something that needs real work.
