Skip to main content
← Back to Articles
Guide Cost Optimization

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.

3 min read By Hermann Lotter

Time to diagnose

~20 min

Most common cause

Forgotten resources

Checks to run

6, in order

SEO Focus Topics

AWS BillingCost AnomalyCost ExplorerAWS Cost Optimization

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.
My AWS Bill Suddenly Doubled: The 20-Minute Triage

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.
Deleting the instance does not delete its snapshots, its unattached volumes, or its elastic IP. All three keep billing after the resource is gone.

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.

HL

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