The total misleads
If cloud cost rises 30% in a quarter, is that bad? It depends. If customers doubled over that time, the cloud became more efficient. If customers did not change, there is a problem. The total cost, on its own, does not distinguish between the two situations.
The unit metric solves that: it divides cost by a measure of business activity. Cost per active customer, per transaction processed, per order, per gigabyte served. It is the number that lets you say whether the cloud is growing faster or slower than the business.
How to build it
- Choose the unit. It has to be tied to how the organisation makes money and be easy to understand outside the technical team. Just one to begin with.
- Measure the volume. From a reliable source and at the same time granularity as the cost (usually daily or monthly).
- Divide the allocated cost. Only the cost attributed to that product or service, not the organisation's total. That is why allocation has to be solved first.
- Review the trend. The absolute value matters less than how it evolves. A metric that falls while the business grows is the best sign of efficiency there is.
How to choose well
| Good unit | Bad unit |
|---|---|
| Relates to revenue (customers, orders, transactions) | Is purely technical (CPU, internal requests) |
| Is understood in a board meeting | Needs explaining every time |
| Is measured automatically and consistently | Depends on a spreadsheet somebody updates by hand |
| Changes when real usage changes | Is constant or arbitrary |
Frequent mistakes
- Using total cost in the numerator. It mixes products with very different economics and the metric stops saying anything.
- Changing the unit every quarter. You lose the historical series, which is exactly what gives it value.
- Watching it without an owner. A metric with nobody to explain its movements becomes a decorative number.
With the unit metric, the conversation changes from 'the cloud is expensive' to 'serving each customer costs us this much, and it is coming down'. It is the basis for budgeting sensibly, which is the next step.
How we apply it: FinOps Engineering.