A cloud bill nobody can explain: how to find the line, and who to make explain it
There is a particular kind of helplessness in a cloud bill that has doubled and an interface that will only tell you the total.
You are not bad at this. The billing model is genuinely complicated: resources are metered on axes nobody thinks about at deployment time — per hour, per gigabyte moved, per request, per gigabyte-month retained, per IP simply existing — and the console's default view is designed to summarise, not to explain. Summaries hide exactly the thing you are looking for.
The good news is that the cause is nearly always findable, and it is nearly always one of a small number of things.
Find the line before you argue about it
1. Get the detailed usage export, not the invoice. The invoice is a summary. The detailed usage or cost export breaks charges down by resource, meter and day. Everything below depends on having it.
2. Diff two months at the meter level, not the service level. "Compute went up £900" is not a finding. "This meter, in this region, went from 40 units to 5,000 units on the 14th" is a finding. Service-level totals routinely hide a new charge behind an unrelated decrease.
3. Find the day it changed. Sort by date and look for the step. A step change on a specific day points at a deployment, a config change, or something that started retrying. A gradual ramp points at growth, retention, or something accumulating that nothing deletes.
4. Check the usual suspects, in this order. Most unexplained bills are one of these:
- Egress. Data leaving the platform, or crossing between regions or zones. Priced per gigabyte, invisible in architecture diagrams, and the single most common surprise.
- Something that retries. A failing job in a loop bills for every attempt.
- Storage that accumulates — snapshots, backups, logs, old versions — where something creates and nothing expires.
- Resources that bill while idle. Provisioned capacity, reserved addresses, load balancers, gateways: these bill for existing, not for being used.
- A tier or plan change applied automatically at a usage threshold.
- Something that was never actually deleted. A "deleted" resource with a retained disk or snapshot behind it.
5. Then go and look at what is deployed, in every region, not just the one you use. Idle resources in a region you forgot about are extremely common and extremely boring, which is why they survive.
When support will not explain it
If you have the meter, the date and the resource and are still being told the charge "reflects your usage", escalate with specifics. Ask for these, in writing:
- The meter definition: what one unit of this specific meter represents.
- The resource identifier generating the charge.
- The rate applied and the rate card it comes from, on the date in question.
- Confirmation of whether any pricing or tier change took effect in that period.
These are answerable questions with factual answers. "Your usage increased" is not a response to any of them, and saying so plainly — once, without heat — moves cases more often than a longer complaint does.
If the charge came from a failure on their side — a service that malfunctioned and retried, a documented outage — say that explicitly and ask for a billing adjustment on that basis. Adjustments happen far more often than people expect, and almost never without being asked for.
The structural complaint
Two things here are worth naming, because they are choices rather than consequences of complexity.
Spending limits mostly do not exist. Alerts do — they tell you after the money is gone. A genuine cap, one that stops the meter, is available for almost nothing that matters. For a company that is an annoyance. For an individual, a student, or a small charity, an unbounded bill attached to a card is a life-altering risk that they were never offered the option to bound.
The pricing detail arrives after the decision. The information needed to predict a cost is technically published, spread across pricing pages, calculators and documentation, in a form that requires you to already know which meter will bite you. Anyone who could work that out in advance would not have been surprised.
To be fair
Metered billing is not a scam. It is the reason you can rent five minutes of an enormous machine, and per-second billing genuinely does pass savings to people who use less. The complexity is largely real complexity, not invented obscurity — there are that many dimensions because the systems have that many dimensions.
And the detailed data does exist. That matters, and it is why the sequence above works at all.
The complaint is the asymmetry. They can meter to the second across a hundred dimensions, and cannot offer a hard cap. That is not a technical limitation. Nobody who has built billing at that resolution is incapable of building a switch that turns it off.
Keep your own record of what you deployed and when. When the bill and the architecture disagree, the one you wrote down yourself is the one that lets you win the argument.