My AWS Bill Suddenly Doubled: The 20-Minute Triage
When an AWS bill spikes overnight, the cause is almost always one of six things. Here is the exact order to check them in, and how to stop the bleeding in the same billing cycle.
Time to diagnose
~20 min
Most common cause
Forgotten resources
Checks to run
6, in order
SEO Focus Topics
Key Takeaways
- • Group Cost Explorer by service, then by usage type, at daily granularity. The spike names itself in two clicks.
- • The six usual suspects, in frequency order: forgotten resources, storage accumulation, data transfer, NAT gateway processing, expired commitments, runaway compute.
- • Deleting a resource does not always delete its cost: snapshots, unattached volumes, and idle elastic IPs keep billing.
The direct answer: where to look first
Open Cost Explorer, set granularity to daily, group by service, and find the day the line bends. Then group by usage type within that service. In two clicks you know what spiked and when. The cause is almost always one of six things, and you can check all six in about 20 minutes.
Do this before touching anything else. Teams that start deleting resources before they have the daily service-level picture routinely kill the wrong thing and leave the actual cause running.
- ✓ Cost Explorer → daily granularity → group by Service: find the bend.
- ✓ Within the spiking service, group by Usage Type: name the exact meter.
- ✓ Compare the spike date against your deploy log and any commitment expiry dates.
Check 1 and 2: forgotten resources and storage accumulation
The single most common cause of a sudden bill jump is a resource someone spun up for a test and never terminated. An oversized EC2 instance, a load-testing cluster, a GPU box for an experiment. It runs 24/7 whether used or not.
Second is storage that accumulates silently: EBS snapshots on a backup policy nobody reviews, CloudWatch log groups with no retention policy, and S3 buckets collecting versioned objects. These grow every day, so the bill climbs a little more each month until someone notices.
- ✓ List instances by launch date and owner tag. Anything untagged and older than a sprint is a suspect.
- ✓ Check EBS snapshot count and total size. Thousands of snapshots is common and almost never intentional.
- ✓ Set CloudWatch log retention. The default is keep-forever, and that default costs real money.
Check 3 and 4: data transfer and NAT gateway
Data transfer is the classic invisible spike. A new integration that pulls data cross-region, a misconfigured CDN origin, or a chatty service talking to a database in another availability zone. None of it shows up as a new resource, only as a bigger transfer meter.
NAT gateway deserves its own check because it double-bills: an hourly rate plus a per-GB processing charge. A workload that starts routing large volumes through a NAT gateway can add thousands a month while every dashboard shows the same instance count.
- ✓ In the spiking service, look for usage types containing Bytes or DataTransfer.
- ✓ Check EC2 Other in Cost Explorer: NAT gateway processing hides there, not under EC2.
- ✓ Cross-AZ traffic between your app and its database is a design smell and a steady leak.
Check 5 and 6: expired commitments and runaway compute
If the spike lands exactly on a month or year boundary, check whether a Savings Plan or Reserved Instance expired. Workloads silently fall back to on-demand rates, which is an instant 30 to 60 percent jump with zero change in usage.
Last is genuine runaway compute: a Lambda function retrying in a loop, a recursive trigger, an autoscaling group whose scale-in policy broke. These are the rarest cause but the fastest growing, so if the daily line is still climbing today, start here instead.
- ✓ Cost Explorer → filter by purchase option On-Demand: a sudden on-demand surge means coverage lapsed.
- ✓ Check Lambda invocation counts and error rates for retry storms.
- ✓ Set a billing alarm now if you do not have one. The second incident should page you, not surprise you.
After the fire: verify against the CUR, then prevent
Cost Explorer is an aggregation layer, and I have seen it disagree with the raw Cost and Usage Report in both directions. Before you report a number to anyone, cross-check the CUR. That habit has saved me from presenting wrong figures more than once.
Prevention is boring and cheap: ownership tags enforced on compute and storage, budgets with alerts at 80 and 100 percent, anomaly detection turned on, and log retention set everywhere. A bill that cannot surprise you is the goal.
- ✓ AWS Cost Anomaly Detection is free and takes minutes to enable.
- ✓ Budget alerts to a channel people actually read, not a mailbox nobody owns.
- ✓ A monthly 30-minute cost review catches drift before it compounds into a spike.
Frequently Asked Questions
Why is my AWS bill still high after I deleted my resources?
Deleting a resource does not always delete its cost. EBS snapshots, unattached volumes, idle elastic IPs, and S3 versioned objects all keep billing after the parent resource is gone. Check EC2 Other and S3 usage types in Cost Explorer for leftovers.
Will AWS refund unexpected charges?
Sometimes, for genuine accidents and first offences. Open a billing support case, explain what happened and what you fixed to prevent recurrence. AWS has no obligation to refund, but goodwill credits for honest mistakes are common, especially on newer accounts.
How do I find out which service caused my AWS bill to spike?
Open Cost Explorer, set granularity to daily, and group by Service to find the day and service where the line bends. Then group by Usage Type within that service to identify the exact meter. This takes about two minutes and works for the vast majority of spikes.
How do I stop an AWS bill spike from happening again?
Enable AWS Cost Anomaly Detection (free), set budget alerts at 80 and 100 percent of expected spend, enforce ownership tags, and set CloudWatch log retention. Most spikes come from resources nobody owns and meters nobody watches.
Sources
About the author
Hermann Lotter
FinOps practitioner who has led cloud and AI cost optimization inside a 180-person organisation, identifying six-figure annual savings across AWS and LLM spend. He writes Easy Entropy from hands-on engagements, not theory. LinkedIn
Free Assessment
Want this outcome in your AWS bill?
Get a free cloud cost analysis and a prioritized optimization roadmap.
Request Free Analysis →Related Articles
Cost Optimization
How to Reduce Your AWS Bill: A 30-Day Step-by-Step Guide
To reduce your AWS bill, work in this order: turn on Cost Explorer and daily CUR to find where the money actually goes, delete idle and orphaned resources, right-size overprovisioned compute and storage, then buy Savings Plans against the baseline that survives. Most accounts that have never been optimized give up 20% to 35% within 30 days, and the first two steps cost nothing and carry no production risk. Buying commitments first is the common mistake: it locks in the waste you have not removed yet.
FinOps
How Much Does a FinOps Consultant Cost in 2026? Real Numbers
Published market rates, the three pricing models, and an honest rule of thumb for when hiring cost help pays for itself, and when it does not.