The cloud bill rose 20% this month. Finance asks why. Engineering says traffic was up. Nobody can say whether 20% more spend for that much more traffic is good, bad or exactly what was expected. A total can only tell you the bill got bigger. Unit economics is how you find out whether it got worse.
What is cloud unit economics?
Microsoft defines it as “the process of calculating the cost of a single unit of a business that can show the business value of the cloud.” The FinOps Foundation words it as bringing together “what an organization spends on technology and the value that technology spending creates.”
In practice: choose one unit, work out what cloud spend it takes to serve it, and watch that number over time. Cost per order, cost per customer, cost per API call. The bill is the numerator. The business is the denominator.
This is not a separate discipline bolted onto FinOps. It is written into the Foundation’s principles: “Unit economic and value-based metrics demonstrate business impact better than just aggregate or categorized technology spend.” If you want the wider picture first, start with what FinOps is.
Why a total bill misleads
A total mixes two things you want to separate: how much you do, and how efficiently you do it. If orders doubled and spend rose 20%, each order got cheaper. If orders were flat and spend rose 20%, something is wrong. The invoice looks identical in both cases.
AWS says the same in its cost optimisation design principles under “Measure overall efficiency”: “Measure the business output of the workload and the costs associated with delivering it. Use this measure to know the gains you make from increasing output and reducing costs.” That is unit economics in one sentence, minus the name.
Resource metrics and business metrics
The Foundation separates two kinds of unit metric, and mixing them up is the commonest way to confuse a room.
| Kind | Examples from the Foundation | Who it helps |
|---|---|---|
| Resource efficiency | Cost per GB stored, per GB transferred, per virtual CPU, per seat used, per token | Engineers tuning how a system runs |
| Business unit | Cost per tenant, per transaction, to serve, per case resolved | Product, finance and leadership judging value |
Cost per vCPU going down is nice. It tells you nothing about whether the product is profitable. Cost per transaction going down tells everyone something. Start with the business metric, and keep a resource metric or two underneath it to explain movements.
How do you pick the unit?
Microsoft’s advice is plain: “Identify what a single unit is for your business – like a sale transaction for an ecommerce site or a user for a social app.” The test is whether the unit moves when your revenue moves. If you sell subscriptions, a customer or tenant is natural. If you process payments, a transaction is. If you run an internal platform, a case resolved or a deployment may be the closest thing.
Do not choose a unit because its data happens to be easy. Do check that it can be measured at all. A good unit with no telemetry behind it is a wish.
How do you work out the cost of one unit?
Microsoft is candid that “Unit economics isn’t a simple task.” Its outline, simplified:
- Map each unit to the services behind it. Compute, storage, networking and data transfer are the usual contributors.
- Start with application telemetry. Log when critical functions run and how long they take, so you can deduce the usage per unit.
- Fill gaps from monitoring data. Where telemetry is missing, use the resource utilisation metrics your cloud provider already collects.
- Split shared infrastructure by usage. Microsoft says to “split the cost of shared infrastructure with utilization data.”
- Decide what to do with the remainder. Some usage never maps back to a unit. Distribute it using the known usage percentages, or treat it as overhead to minimise on its own.
The Foundation’s version adds validation: confirm the metrics affect the decisions they were meant to, and set a regular review to adjust or retire them. A metric nobody acts on is just a number on a wall.
Start small
The Foundation’s maturity model is refreshingly modest. At Crawl, unit economics is “basic and mostly technical”, focused on direct variable cost in one category such as public cloud, and its main value is cultural: getting engineers to think about design choices in cost-per-unit terms. At Walk, product and engineering teams build their own with FinOps practitioner support and begin to count fully loaded costs. At Run, every operational scope has defined unit metrics, and they shape decisions on architecture, build versus buy and pricing early.
A practical first pass for a team that has never done this:
- Pick one product or service, not the whole estate.
- Pick one business unit metric and one resource metric.
- Use tagged or allocated costs for that service, and note what is not covered.
- Publish the number monthly, next to the total bill, with its caveats.
Allocation comes first, because you cannot divide a cost you cannot attribute. If that is your gap, showback or chargeback is the better place to begin, and how often to review cloud costs covers the rhythm for looking at the result. More on how Auris approaches this is on the FinOps page.
What can go wrong
- A unit that nobody owns. If no team can change the number, no one will.
- Pretending the allocation is precise. Shared costs are estimated. Say so beside the figure.
- Chasing the lowest number. The aim is value, not a minimum. A higher cost per unit can be the right trade if it buys quality or speed, which is the point of the Foundation’s call for conscious trade-offs.
- Changing the definition every month. A trend needs a stable unit. Revise deliberately, and note when you do.
The bottom line
Cloud unit economics turns “the bill went up” into “each order costs this much, up or down from last month.” Pick one business unit, map the services behind it, be honest about what you cannot attribute, and track it beside the total. A rough cost per unit that people use beats a precise one that nobody reads.