On this page
Why Is My Cloud Bill So High (and How Do I Find the Leak)?
Unexpected cloud bills are almost always one of a handful of causes. Learn which, how to find yours in the billing console, and how to stop it recurring.
Quick answer
Surprise bills are nearly always one of five things: idle resources, accumulating snapshots, data transfer, per-hour managed services, or a runaway loop.
Billing is metered hourly but invoiced monthly, so a single bad night becomes a large number.
Start in the provider’s cost breakdown, sorted by cost descending, grouped by service and by tag.
Set a budget alert before you optimise. It is the control that stops the next incident, and it takes two minutes.
Why is my cloud bill so high?
A cloud bill that surprises you is rarely a mystery. It is almost always one of a small number of well-known mechanisms, and providers make the data available — the bill is just not organised in a way that answers “what changed?” at a glance.
The structural reason these surprises happen is the billing model itself. Most resources are metered continuously, by the hour or the second, but you are invoiced monthly. So a loop that ran for ninety minutes on Tuesday can produce a line item larger than a month of normal usage, and you discover it four weeks later with no way to attribute it in the moment.
That gap between “it happened” and “you found out” is the actual problem to solve, and it is why alerting matters more than optimisation.
Where this bites vibecoders
The specific way this bites vibecoders is the demo that never got turned off. An assistant sets up a scheduled job, a preview environment, a test database, or a second region while debugging something at 2am, the fix lands, and the resource stays — running, idle, and billing, invisibly, for months. Nothing in the code or the git history records its existence, so the trail goes cold. A monthly list of “things I created and why” is what prevents this.
What are the most common causes?
1. Idle resources you forgot. A stopped VM still has its disks attached. An unattached load balancer, a forgotten test instance, a second NAT gateway, an old container service cluster. The most common single line item in a surprise bill is something that has no traffic and has been running since March.
2. Snapshots and backups accumulating. Each snapshot is a full copy of a volume at that moment. Automated retention policies that keep 30 daily and 30 weekly and 12 monthly snapshots multiply the cost of a volume every time it grows. Backup storage is usually a rounding error next to this.
3. Data transfer. Traffic into a provider is frequently free; traffic out is billed per gigabyte, often at a higher rate for the first few terabytes. This is the cost people forget, because it is triggered by your users rather than by your configuration. A popular post, a bot scraping your site, or a misconfigured retry loop all show up here.
4. Managed services billed per hour regardless of use. Load balancers, NAT gateways, API gateways, container orchestrators, and managed databases have an hourly floor. A load balancer you left enabled for a month costs a month of charges whether it served ten requests or ten million. This is the failure mode most specific to the “I scaled up for a launch and never scaled back” pattern.
5. A runaway loop. A retry with no cap, a queue consumer that re-processes failed messages forever, a cron job that overlaps itself, a memory leak driving autoscaling. This produces the genuinely frightening numbers — orders of magnitude above normal — and it is worth assuming this first if your bill jumped rather than crept.
6. Free tier expiry. A generous trial or free tier ending is not a leak, it is a cliff. If your usage was near the limit, crossing it changes the price of everything at once.
How do I find what is costing money?
Every major provider gives you a cost breakdown; the work is in reading it correctly.
1. Break cost down by service, sorted descending. The top three services are usually 80% of the bill, and often one service is the entire story. The AWS Cost Explorer’s default view groups by service, which is the right first cut.
2. Break it down by resource. This is the step that actually finds the leak. The same single NAT gateway or unattached 500GB volume will not be visible in a service-level total if it is small relative to the total. Grouping by resource and sorting descending makes the individual offenders obvious.
3. Check the regions and accounts you are not using. A large proportion of surprise bills trace to a region you deployed to during an experiment. Most consoles group by region, and the us-east-1 habit means resources elsewhere are easy to forget.
4. Use tags, even roughly. Even tagging everything app: my-project is enough to separate “this project’s resources” from “everything else in the account”, which is the question you actually need answered.
5. Look for a step change, not just a total. The right question is not “is my bill high?” but “what is different about this month?”. Providers’ anomaly detection exists for exactly this and will often point at the resource before you would have found it.
6. Cross-check against what you know you run. List the services you deliberately use, and compare. The gap between the two lists is your answer.
How do I stop it happening again?
Set a budget alert before you optimise. This is the highest-value action and it is usually two minutes. Most providers can email or page you at 50%, 80%, and 100% of a threshold. You do not need the alert to prevent the cost — you need it to convert a four-week mystery into a message you read in minutes.
Add a hard stop for anything that can scale. Where a provider supports a spend cap, a maximum instance count, or an autoscaling ceiling, set it. The blast radius of a runaway loop should be bounded by configuration, not by how fast you notice.
Delete, do not just stop. Stopping an instance leaves its volumes and often its elastic IP billing. Confirm the disk snapshots are removed as part of shutting it down.
Tag on creation. A tag you are forced to supply at creation time is the version that actually happens; a convention you adopt retroactively is the version that does not.
Review monthly, briefly. Ten minutes at the end of the month — top ten resources by cost, and confirm each is one you still want — catches the class of problem where nothing changed but something quietly grew.
Audit third-party access. A third-party integration with a key to your account can create resources you never see. The Non-Human Identity view of your account is worth doing alongside the cost review, because the same credential is often responsible for both the spend and the risk.
Where AI coding assistants get this wrong
- Suggesting a smaller instance when the actual cause is a resource that should not exist, leaving the leak in place.
- Recommending reserved instances or savings plans before you know what is actually running — a commitment on unused capacity makes the bill worse.
- Adding caching or downscaling without first identifying the resource, so nothing improves and the diagnosis is now muddier.
- Missing the un-billed-but-billing leftovers: attached volumes, public IPs, snapshots, load balancers, NAT gateways.
- Not considering data transfer, which is usually the largest line item for a small app with real traffic.
- No budget alert, so the same class of problem recurs regardless of what you fix this time.
- Treating “it’s only a few dollars a month” as acceptable, across twenty forgotten resources.
Checklist
- Pull the cost breakdown by service, sorted descending, for the current month.
- Pull the breakdown by resource, sorted descending — this is where the leak is visible.
- Group by region and account to find resources outside your primary setup.
- List every resource you believe you are running, and diff it against the console.
- Set a budget alert at roughly 50% of a threshold you can afford.
- Set autoscaling maximums or spend caps on anything that can grow.
- Delete stopped instances and their attached volumes, snapshots, and elastic IPs.
- Check your snapshot retention policy and prune old backups.
- Review data transfer charges separately from compute.
- Confirm the free tier or trial end date, if one applies.
- Tag resources at creation so future reviews are a filter rather than an investigation.
- List every third-party integration with access to the account, and remove the ones you no longer use.
FAQ
Why did my cloud bill suddenly spike?
Almost always one of a small number of causes: a resource you created and forgot, a scheduled job that runs far more often than you think, data transfer charges that scale with traffic, a load balancer or NAT gateway billing per hour whether or not you use it, or a snapshot/backup left behind. Because billing is metered hourly and reported monthly, a runaway for one night can land as a four-figure invoice.
What are the most common causes of a surprise cloud bill?
Idle resources you stopped using but did not delete, storage snapshots accumulating, data transfer out of the provider, managed services billed per hour regardless of traffic, and runaway scaling from a retry loop or a hot loop. The last is the one that produces the genuinely alarming invoices, and the fix is usually to set a hard budget alert rather than to hunt for the root cause alone.
How do I find what is costing money?
Use the provider’s cost breakdown by service and by resource, sorted by cost descending, and compare it against what you believe you are running. Most providers also have a cost anomaly detection feature. If the spike is recent, the fastest signal is often simply listing resources in the regions and accounts you are not currently using.
Does a stopped instance still cost money?
The compute usually stops, but very often the attached storage does not. A stopped instance keeps its EBS or disk volumes, and volumes keep their snapshots, so the bill keeps accruing. Public IPs and some managed services also continue to bill. Deleting the instance without deleting its volumes is one of the most common reasons a “stopped” environment keeps costing money.
Is the free tier the problem?
Sometimes, and it is worth checking the dates first because it is a five-second lookup. Free tiers and trials have hard end dates, and crossing one changes the price of everything rather than adding a single line item. If your usage was near the limit, the step change on the billing date is expected behaviour rather than a leak.
Should I buy reserved instances to cut costs?
Only once you know what is running and how reliably. A commitment pays for capacity whether or not you use it, so committing against unused resources makes the bill worse immediately. First remove what should not exist, establish a steady baseline, and only then consider a commitment for the part that runs continuously.
Related topics
- Journey: Find the Money in Your Cloud Bill — the ordered working session for acting on this page.
- How to Reduce Your Cloud Bill Without Breaking Production
- What Is FinOps (Cloud Cost Management)?
- Why Is My Kubernetes Bill So High (and How Do I Cut It)?
- Connection Pool Exhausted: What It Is and How to Fix It
- What Is a Non-Human Identity (NHI)?