Your AWS bill spiked overnight: the line items to check

You open the AWS console with your coffee and the cost graph has a cliff in it. Yesterday's run rate doubled overnight, nothing obvious shipped, and the bill is climbing while you read this. The instinct is to scroll the whole invoice line by line - which is slow, stressful, and usually the wrong order. Overnight spikes are not random. They come from a short, predictable list of line items, and if you check them in the right sequence you can name the cause in minutes instead of an afternoon.

This is that runbook: the line items that cause AWS bills to jump overnight, in the order they are worth checking, plus the one console view that finds the exact charge fast. It is written for the moment you are in right now - bill is up, cause unknown, and you need an answer before the standup.

First, open the one view that actually finds it

Before you guess, look. Open Cost Explorer, set granularity to daily, and group by usage type (not service). The spike will show up as one or two usage types that jumped - something like DataTransfer-Out-Bytes, NatGateway-Bytes, or BoxUsage for a specific instance size. That single grouping turns "the bill went up" into "this exact line went up," which is the whole game. If you want the deeper FinOps workflow around this view, we wrote it up in finding a billing spike with Cost Explorer.

The line items that cause overnight spikes, in order

Now that you can see which usage type moved, here is what each one usually means and where to look. Work the list top down - the first few cause the large majority of real spikes.

1. NAT gateway egress

The single most common surprise. A NAT gateway charges both an hourly fee and a per-gigabyte data-processing fee. If a workload in a private subnet suddenly pulls or pushes a lot of data through it - a backup job, a chatty container, a misrouted S3 call that should have used a VPC endpoint - the per-gigabyte line explodes overnight. The fix is often a VPC endpoint so that traffic to AWS services never touches the NAT gateway at all.

2. Cross-AZ and inter-region data transfer

Traffic between availability zones bills per gigabyte in both directions. A new replica, a chatty service talking to a database in another AZ, or a job moving data across regions can quietly add hundreds of dollars. Group by usage type and look for DataTransfer-Regional-Bytes or inter-region lines.

3. Data transfer out to the internet

Serving more traffic to users - a viral spike, a new large asset, a missing CDN cache - bills per gigabyte as DataTransfer-Out-Bytes. If this is your spike, the answer is usually CloudFront in front of the origin so most bytes are served from cache at a lower rate, not straight from your instances or S3.

4. A forgotten or runaway instance

Someone launched a large instance for a test and never terminated it, or an auto-scaling group scaled out and never scaled back. Group by usage type and look for a BoxUsage line for an instance size you did not expect. GPU and large-memory instances are the painful ones - a single forgotten GPU box can be the whole spike on its own.

5. Idle resources that bill whether or not you use them

Unattached EBS volumes, idle load balancers, provisioned IOPS you no longer need, unattached Elastic IPs, and over-provisioned serverless capacity all bill on a standing basis. These rarely cause a sudden overnight jump on their own, but they inflate the baseline the spike sits on - and cleaning them up is the fastest permanent saving. Our list of immediate AWS savings walks through the cleanup, and for AI and ML workloads specifically the biggest cost traps are worth a separate pass.

Stop the bleed, then prevent the next one

Once you have named the line, act in two steps. First, stop the bleed: terminate the runaway instance, kill the job hammering the NAT gateway, or put a cache in front of the egress. Second, prevent the repeat - a VPC endpoint so AWS-service traffic skips the NAT gateway, a CloudFront distribution for public egress, an auto-scaling policy that actually scales back in, and a budget alert with a threshold a little above your normal run rate. The teams that get surprised twice are the ones who fixed the symptom and skipped the second step. Wiring these guardrails in is the core of any AWS consulting engagement, and keeping the bill flat as traffic grows is what ongoing managed cloud services are for.

Set the alert you wish you had this morning

The reason this spike hurt is that you found it by looking, not by being told. AWS Budgets lets you set a cost or usage threshold and get an email or alert the moment you cross it - set one a little above your normal daily run rate and the next anomaly reaches you while it is small. Pair it with a usage-type budget on data transfer specifically, since that is where the nastiest surprises hide. An alert that costs nothing to set is the difference between a fifty-dollar blip and a five-thousand-dollar month-end shock.

FAQ

Why did my AWS bill spike overnight with no deploy?

Most no-deploy spikes are data transfer or a resource that changed behaviour, not new code. A backup job, a chatty service, or a misrouted call can push gigabytes through a NAT gateway or across availability zones, each billed per gigabyte. Open Cost Explorer at daily granularity grouped by usage type to see which line actually moved.

What is the most common cause of an unexpected AWS charge?

NAT gateway data processing and cross-AZ data transfer are the most common surprises because they bill per gigabyte and are easy to trigger accidentally. After data transfer, the usual causes are a forgotten large or GPU instance left running and idle resources like unattached volumes and load balancers inflating the baseline.

How do I find exactly what caused the spike?

Open Cost Explorer, set granularity to daily, and group by usage type rather than service. The spike appears as one or two usage types that jumped - for example NatGateway-Bytes or DataTransfer-Out-Bytes - which points you straight at the cause instead of making you scroll the whole bill.

How do I stop AWS bill spikes happening again?

Add a VPC endpoint so AWS-service traffic skips the NAT gateway, put CloudFront in front of public egress, make sure auto-scaling actually scales back in, and clean up idle resources. Then set an AWS Budgets alert just above your normal run rate so the next anomaly reaches you while it is still small.

The bottom line: an overnight AWS spike feels like a mystery, but it is almost never one. Look in Cost Explorer first, work the line items in order - data transfer, then forgotten instances, then idle waste - stop the bleed, close the leak, and set the alert. Do that and the next spike is a notification you act on early, not a number you explain after the fact.