The anatomy of cloud bill shock and how to make your cloud bill boring
TL;DR
Cloud bill shock is rarely a billing error. The meter ran on things you forgot, never knew were billable, or left out of the estimate; roughly 29% of IaaS and PaaS spend is estimated to be wasted. The fixes are cheap: scheduled spend checks, tags, infrastructure as code, shutting down what sleeps, and reading the price list first. Give each an owner, and prefer providers with few metered dimensions and a public price list.
Someone spun up a few cloud resources for a test. The test ended. The resources were not terminated. Stop me if you’ve heard this one before. A month later, an invoice arrived that was ten or a hundred times larger than expected, and the person telling the story still remembers the exact number. These stories are so common that the phenomenon has its own name, cloud bill shock. It even has its own genre of blog post, generally written in the heat of the moment as the authors solemnly swears to begin some sort of migration journey.
Cloud bills are typically correct
I personally haven’t had the misfortune to face this problem, but like many of you I have heard the stories. Most recently by a partner of ours who helped a large company migrate into Cleura, specifically because of a cloud bill shock and the anger that came with it.
The common denominator, which is often overshadowed by the large numbers and disbelief, is that in nearly all of the cases the bill turned out to be correct. The provider charged for cloud resources that actually ran and the customer simply forgot that they were running, or did not know they were billable, or never thought to include them in the estimates in the first place.
Pay-as-you-go is great but comes with a built-in asymmetry
Pay-as-you-go pricing is one of the cloud’s genuine advantages. No capital expenditure, no capacity planning years in advance, scale up or down as easily as one, two, three.
Don’t get me wrong. The granular way of paying for cloud resources is both fair and great in all senses of the word but it also has a built-in asymmetry. Creating or allocating a cloud resource only takes a simple API call and a few seconds of attention. Remembering that the resource exists or what it does, perhaps even after the colleague who created it has switched teams, is a different thing entirely.
The meter doesn’t really care and it never forgets. What’s been consumed has been consumed.
The “cloud waste” that this produces is not a rounding error by any means. Flexera’s 2026 State of the Cloud research estimates that roughly 29% of IaaS and PaaS spend is waste. Separate research from CloudZero found that only about a third of organisations have an accurate picture of where their cloud budget goes.
The dramatic stories that reach us on LinkedIn are evidently just the visible tip of the proverbial iceberg.
Start treating every cloud resource as a small subscription you have personally signed on to. If nobody on the team can say what a resource is for, assume that it’s just burning cash.
Two kinds of meters: allocation and usage
Here is a distinction that makes the rest of this article easier to reason about.
Priced per allocation
Some resources are allocation-priced. You pay for what you reserve, whether you use it or not. A VM with 4 vCPUs and 16 GB of RAM costs the same per hour at 3% load as at 97%, and a 500 GB volume costs the same empty as full. The upside of this model is that you are usually informed and know the price the second you deploy.
Priced per actual usage
Other resources are priced per actual usage and you pay for what actually happens. That would be per: gigabytes transferred out, API requests, function invocations, queries. Naturally, nobody can tell you that cost up front, because it all depends on your future traffic, your users and, occasionally, your bugs.
Everyday vs. viral stories
Most platforms mix both. The large US clouds wrap allocation-priced VMs in a thick layer of usage-priced dimensions. Cleura Cloud sits almost entirely on the allocation side. Just keep the distinction in mind. Most everyday surprises come from allocations nobody remembered making, but the loudest and most viral stories tend to come from the usage side of the meter.
A few famous examples from the usage side
- We Burnt $72K testing Firebase + Cloud Run on Google Cloud (Milkie Way)
- How an empty S3 bucket can make your AWS bill explode (Maciej Pocwierz)
- Beware RunOnStartup in Azure Functions – a serverless horror story (Tom Wright)
- How we spent $30K in Firebase in less than 72 hours (Hacker News)
- Netlify sent me a $104K bill for a simple static site (Hacker News)
- Cara’s viral week led to ~$98K in Vercel Functions costs (InfoQ)
- Recursive serverless functions on AWS, Azure and Google Cloud (InfoQ)
- ServerlessHorrors: a running archive of these stories
The usual suspects of cloud bill shock
The cloud charges that tend to take people by surprise come from a short and remarkably stable list.
- Forgotten compute: The test server that outlived the test. Development environments that continues to run at 03:00 because nobody scheduled them off.
- Orphaned resources: Volumes or snapshots that survived the deletion of the server they were attached to. Reserved public IP addresses pointing at nothing. Snapshots from 2023.
- Free-tier expiry: Free tiers end quietly, and the resources provisioned during the free period keep running at full price afterwards.
- Licensed software: Commercial software metered per vCPU multiplies innocently when someone resizes a server upwards. Windows Server and SQL Server are the classic examples; on most price lists, ours included, they are charged linearly per pair of vCPUs, so doubling a server’s cores doubles the licence line too. Vendor price adjustments also arrive whether or not you noticed the licence.
- Automation without limits: Auto-scaling and serverless functions tend to work best when you least want them to, particularly during runaway loops and attacks. All joking aside, try to implement guardrails and limits to your automations so that they can’t spin up resources indefinitely.
There is one more line item that perhaps should be added to this list and that is egress fees. Devil’s spawn according to some, fair according to some, but almost never accounted for when the budget is guesstimated. I’ll cover that topic in a different post and link it from here when it’s out.
All of these are preventable
Nothing on this list is what I’d call exotic, and everything on it is preventable, so why does it keep happening? In my, and my colleagues, experience the honest answer is that the task of noticing these things is usually assigned to nobody in particular. Cost review sits in the gap between engineering (who see the resources but not the invoice) and finance (who see the invoice but not the resources).
Create a monthly, or why not even a weekly, cleanup schedule:
List volumes that aren’t attached to VMs, addresses not associated with anything, and snapshots older than your retention policy actually requires. Delete what fails the test. Thirty minutes a month is considerably cheaper than the alternative.
Defences that can prevent cloud bill shock
Cloud bill shock responds well to a handful of boring habits. None of them requires new tooling or budget, just an appointed owner. I bet you could even have your latest and greatest AI companion do some of this for you.
One honest caveat before the list. These habits catch the slow leaks, the kind of waste the industry’s 29% figure describes: idle resources, oversized instances, environments nobody switched off. The habits are weaker against the sudden kind of disaster, where a runaway function or an attack turns a five-dollar bill into a five-figure one before any alert has fired. That failure mode needs different tools like caps that pause instead of alert, limits on what can scale, and isolation between projects. We will cover it in a piece of its own. For now, know that the habits below solve the most common problems, not the catastrophic ones.
Watch your spending from day one
If your platform offers budget alerts, use them, and set the threshold below your pain point rather than at it. Where alerts are not available, two habits can do the same job: on some allocation-priced platforms such as Cleura Cloud, the hourly and estimated monthly cost is shown before you deploy, so note it down; and where billing data is available via API, a scheduled spend check is a short script away. Remember that alerts and checks only report spending, they don’t stop it, and on some platforms the billing data they rely on lags a full day behind reality.
Tag everything
A simple convention (project, environment, owner) turns an unreadable invoice into a question that can be answered. Untagged resources should be on your list of deletion candidates.
Make more use of Infrastructure as Code
Resources created outside your OpenTofu, Ansible or Heat definitions are invisible to your review process, and invisible resources tend to drift.
Shut down what sleeps
Non-production environments rarely need to exist outside working hours. Scheduling them off removes a large share of their cost with no loss of function.
Read the price list
Ten minutes with the price list, before provisioning, answers most of the questions the invoice would otherwise answer expensively.
Scrutinise thoroughly on the supplier side
Everything that I have written above sits on the customer’s side of the ledger. Cloud bill shock also has a supply side, because pricing models differ enormously in how many jump scares they are capable of causing.
When evaluating any IaaS provider, five questions are worth considering when it comes to their price list:
- Is there a single public price list, or does pricing require a sales conversation?
- What does inbound and outbound data transfer cost, exactly, per GB?
- Are there per-operation charges (API requests, IOPS, retrievals) that scale invisibly with usage?
- What do public IP addresses cost?
- Is there a calculator you can use before creating an account?
Lets keep this list clean and professional, but on an honest and personal note – there should be a sixth item in that list; “Can you read the price list without holding a PHD in cloud pricing”.
The Cleura example
We can use Cleura Cloud as an example here, not least because the answers are short.
- Pricing sits on a single public page found at https://cleura.com/cloud-pricing.
- Resources are monitored by the second, calculated by the hour and billed monthly, without long-term commitments.
- Inbound data transfer is free on both Cleura Public Cloud and Cleura Compliant Cloud. On Compliant Cloud, outbound transfer is also priced at €0 per GB; on Public Cloud, egress is charged per GB at a rate currently at €0.02875/GB.
- IPv6 addresses are free, IOPS carries no separate charge.
- A public cost calculator lets you estimate a configuration.
Just to be perfectly clear about the limits of this argument: There are no pricing models that makes carelessness cheap or free of charge. A forgotten server costs money everywhere, in our cloud too. The claim I’m are actually making is narrower. The fewer metered dimensions a bill has, and the more visible each one is in advance, the smaller the space in which a surprise can hide.
You should be able to find the answers to five simple questions on pricing using public information.
If you can’t – great, that tells you something too.
Additional reading
- Cleura Cloud pricing and cost calculators
- AWS documentation: Understanding unexpected charges. The providers’ own catalogue of ways bills surprise people is instructive reading.
- The Register: 37signals completes its cloud exit, including the waived egress fees.
Özgür Bal
Marketing Manager · Cleura AB
Özgür is the Marketing Manager at Cleura. He works across brand, communications, content and go-to-market strategy, with a particular focus on cloud infrastructure and digital sovereignty.
Visit Cleura Cloud Guide
