Unexpected cloud bills are common enough to be a recognised category of problem, from individuals receiving alarming charges to organisations discovering that spending has grown far beyond projections.
The reasons are structural, and understanding them helps whether you're running a personal project or a substantial deployment.
The pricing model
Cloud services are generally priced by consumption across multiple dimensions simultaneously: compute time, storage volume, data transfer, requests, and various per-service charges.
This is genuinely fairer than fixed pricing in many respects — you pay for what you use rather than for capacity you might use.
It also means cost is a function of behaviour rather than a fixed commitment, and behaviour is harder to predict than a subscription.
Where costs hide
Data transfer out. The classic surprise. Moving data into a cloud provider is frequently free or cheap; moving it out costs, and at volume the cost is substantial.
This asymmetry has been criticised as creating lock-in, since migrating away means paying to extract your own data. Regulatory attention in some jurisdictions has prompted changes, including free egress in some circumstances, and the general pattern persists.
Requests rather than volume. Some services charge per operation. A workload making a very large number of small requests can cost more than one moving considerably more data in fewer operations, which is counterintuitive.
Resources left running. Instances started for testing and forgotten. Storage volumes detached from deleted instances but still billed. Snapshots accumulating.
This is probably the largest single source of waste, and it's entirely mundane.
Cross-zone and cross-region traffic. Traffic between availability zones is frequently charged. An architecture distributed for resilience can generate substantial internal transfer costs that nobody planned for.
Managed service premiums. Managed databases and similar services cost considerably more than running the equivalent yourself, in exchange for operational burden being removed. That's frequently a good trade and it should be a deliberate one.
Support plans and licensing. Priced as a percentage of spend in some cases, which means they scale with everything else.
Why estimation is hard
Several compounding factors.
Pricing pages are complex, with numerous dimensions and regional variation. Calculating a realistic estimate requires understanding your workload's behaviour in detail.
Free tiers create a discontinuity. Costs are zero until a threshold, then rise, which means early usage provides no signal about eventual cost.
Autoscaling means capacity responds to demand, so a traffic spike produces a cost spike. That's the feature working correctly and it's not predictable.
And billing arrives after the fact, monthly. A misconfiguration can run for weeks before appearing on an invoice.
The runaway scenarios
Specific patterns that produce dramatic bills.
Recursive triggers. A process that writes output which triggers the same process. Runs indefinitely, generating charges at machine speed.
Compromised credentials. Leaked keys used to run compute at scale, generally for cryptocurrency mining. Bills in these cases have reached very large sums within days.
This is a specific and serious risk for anyone committing credentials to a repository, which happens more often than it should.
Unbounded retry loops. A failing operation retried indefinitely, each attempt billed.
Public storage with unexpected traffic. A file that becomes popular, generating egress charges proportional to its popularity.
What actually controls cost
Budgets and alerts. Set them before deploying anything. Alerts at multiple thresholds — a warning well before the level that would concern you.
These are free and the single most useful control available.
Hard spending limits where offered. Some services allow a cap that stops resources rather than only alerting. Where available, this converts an unbounded risk into a bounded one.
Tagging. Labelling resources by project, environment and owner. Without it, an invoice is one number and attribution is impossible.
Regular review of running resources. A scheduled check for things nobody is using. Most organisations doing this for the first time find substantial waste.
Lifecycle policies on storage. Automatic transition of older data to cheaper tiers, and deletion of things with no retention requirement.
Credential hygiene. Short-lived credentials, scanning repositories for secrets, and least-privilege permissions. This addresses the highest-severity scenario.
Commitment discounts, carefully. Reserved capacity and savings plans offer substantial discounts in exchange for commitment. Worthwhile for predictable baseline load and a liability if usage changes.
The strategic question
Worth asking periodically. Cloud is not automatically cheaper than alternatives.
It's cheaper for variable workloads, for avoiding capital expenditure, and for accessing capabilities that would be impractical to build.
It's frequently more expensive for stable, predictable, high-volume workloads, and several organisations have publicly moved substantial workloads back to owned infrastructure on cost grounds.
The honest answer depends on the workload, and the assumption that cloud is inherently the economical choice is one that deserves periodic examination rather than acceptance.
The free tier trap
Worth its own warning, because it catches individuals and students particularly.
Free tiers are generous and bounded, and exceeding them frequently produces charges at standard rates rather than a hard stop. A tutorial followed slightly wrong, or a resource left running after an exercise, can generate charges from an account that appeared to be free.
Several providers have introduced spending limits for accounts of this kind, and coverage varies.
The practical protection is the same as for any account: set a budget alert at a low threshold immediately on creating the account, before deploying anything, and check what happens when a free tier limit is reached rather than assuming it stops.