A platform team presents the monthly cloud cost. It went up eleven percent. The room reacts as though something went wrong, an optimisation project is commissioned, and three engineers spend a month finding savings.
Nobody asked what revenue did in the same period. It went up nineteen percent. The cost per customer fell, the platform got more efficient, and the company just spent a month of engineering to optimise a number that was already improving.
The absolute bill is close to meaningless on its own. It is an input cost for a business that is presumably growing. The question worth asking is whether each unit of the thing you sell is getting cheaper or more expensive to serve.
Choosing the unit
The unit has to be something the business already counts, or nobody outside engineering will use it.
For most subscription software it is cost per customer or per account, sometimes split by plan tier. For usage-priced products it is cost per transaction, per API call, per document processed. For marketplaces it is per order or per listing. For an AI feature it is cost per query or per conversation, which is the shape covered in what an AI automation costs per run.
Two rules. Pick a unit that appears in a board deck, so the two numbers can sit next to each other. And pick one, not five. A single number tracked for a year is worth more than a dashboard of six that nobody trusts.
Then compute the derived figure that actually moves decisions: infrastructure cost as a percentage of revenue, or gross margin per customer. That is the version a chief financial officer can act on.
Attribution, and the shared cost problem
Direct costs are the easy part: the compute serving a tenant's requests, their storage, their database.
The hard part is that most of the bill is shared. The control plane, the load balancer, the observability stack, the CI pipeline, the non-production environments, the platform team's own tooling. Split it and the arithmetic is contestable; leave it out and the number is wrong in a way that flatters you.
Three approaches, in the order we use them:
- Proportionally to direct cost. Simple, defensible, good enough for almost everyone.
- By a usage driver such as request count or data volume, when one driver clearly dominates.
- Held as a separate platform cost line, reported alongside but not distributed. Honest, and it makes the fixed cost of being in business visible, which is often the more useful insight.
Whichever you choose, show the direct and the allocated portions separately. A team or an executive who can see the split accepts the total; one who sees a single blended figure disputes it.
The technical prerequisite is the same one that underlies everything else in this area: tagging good enough that cost resolves to a workload, and in a shared cluster, a working split by namespace as described in splitting a shared cluster's bill.
Where the interesting findings are
Once you have cost per customer, the average is the least interesting output. The distribution is where the work is.
The long tail of expensive customers. In nearly every estate we have measured, a small number of accounts consume a disproportionate share of infrastructure. Usually it is legitimate: they are large. Sometimes it is not, and a single customer on a flat-rate plan is running a query pattern that costs more than they pay. You cannot find that without per-customer attribution, and once found the fix is usually a product decision rather than an engineering one.
Margin by plan tier. The free tier is expected to lose money. The question is by how much, and whether the entry-level paid tier actually covers its serving cost. Teams are regularly surprised to find that a cheap tier with generous limits is the one destroying margin.
Cost per customer over time. The trend is the health metric. Flat while customer count grows means the platform is scaling sublinearly, which is what you want. Rising means something is scaling superlinearly, and the cause is usually a per-tenant fixed cost: a database per customer, a dedicated queue, a namespace with its own baseline workloads.
Feature-level cost. If a feature can be attributed, you learn which ones are worth their serving cost. An AI feature with heavy inference cost and low adoption is a candidate for a cheaper model or for removal, and neither conversation is possible without the number.
The conversation this enables
This is the actual point. It changes what engineering can say to the rest of the company.
"Our cloud bill went up 11 percent" invites a cost-cutting response. "Cost per customer fell 7 percent while we onboarded 40 new accounts" is a report of a system working. Same underlying data, completely different meeting.
It also changes how optimisation work gets prioritised. Not "reduce the bill" but "this tier has negative margin" or "this customer segment costs three times the average to serve". Those are statements that connect to pricing, packaging and product decisions, which is where the larger levers are.
And it makes capacity planning honest. If cost per unit is stable, forecasting next year's infrastructure cost is arithmetic on the sales forecast rather than a guess.
Getting to a first number
Do not build a data warehouse. The first version should take a week.
Export the last three months of billing data with tags. Group by the tags that identify workload and environment. Separate direct from shared. Pull the customer or transaction count for the same months from the product database. Divide. Put it in a spreadsheet and show it to one person in finance to sanity check the denominator.
The first number will be wrong in the third decimal place and directionally right, which is all it needs to be. Refine once it is being used, because a number nobody looks at does not deserve precision.
Then automate it into a monthly report that arrives without anyone running it, and track the trend rather than the level.
The things people forget
- The denominator has to be defined. Active customers, paying customers, and accounts created are three different numbers and people will use them interchangeably.
- Discounts change the numerator. Use effective rates after commitments, not list price, or the ratio is inflated.
- Non-production is a real cost of doing business. Include it, in the shared line.
- One-off migration costs distort a month. Annotate them rather than letting them look like a trend.
- Cheaper per unit is not always better. Cutting cost per query by degrading latency can cost more in churn than it saves.
What to do this week
Take last month's cloud bill, take the number of active customers from the same month, and divide. Then do it for the same month last year. Those two numbers, on one line, are more useful than any cost dashboard you could build this quarter, and they take an hour. We produce this in the first week of the cost phase of a cloud engagement.