DevOpsInterviews logo
← 🧰 Platform & Cloud Economics
Foundational

A total nobody can divide is unmanageable

Cloud spend rising is not information. Cost per unit of business value is, because it separates a growing company from a leaking one, and those need opposite responses. Getting to that number is mostly an attribution problem, which is why tagging is the first project and not the tedious one.

TL;DR: Pick the unit the business already counts, cost per order, per active user, per ticket resolved, per terabyte indexed, and divide. If the total and delivered volume both tripled, unit cost is flat; check quality and revenue to judge whether that growth is worthwhile. If unit cost tripled, investigate workload mix, prices, quality targets and resource efficiency before calling it a regression. Without the denominator every conversation is a negotiation about whether the number feels high.

Why the total is the wrong number

A bill grew 40 percent this quarter. Is that good?

There is no answer, and that is the problem. The company may have grown 60 percent, in which case efficiency improved. It may have grown 5 percent, in which case something is wrong. The total alone supports both stories, so the conversation becomes a contest of anecdotes, and the usual outcome is a blanket instruction to cut costs that lands equally on the team that caused it and the team that did not.

The denominator

Pick a unit the business already measures. Not a technical one: cost per pod tells a platform team something and tells a CFO nothing.

  • an e-commerce platform divides by orders
  • a SaaS product divides by active accounts, or by seats
  • a data platform divides by terabytes processed, or by pipelines served
  • a support product divides by tickets deflected
  • an AI feature divides by whatever it produces: summaries, resolutions, documents indexed

Then the same 40 percent has a meaning. It is either a margin improvement, a margin problem, or a mix shift, and each has a different owner.

Attribution is the actual work

Dividing requires knowing which spend belongs to which product, which means tagging, which means enforcement. Optional tags produce a large unattributed bucket, and that bucket becomes the whole conversation. Validate required tags at provisioning where the resource supports them. Use account, subscription, project or allocation mappings for charges that cannot carry those tags, and retain an explicit unattributed category until reconciled.

Shared infrastructure needs a documented allocation rule, and any rule you can defend is better than none. Split the cluster's cost by allocated resources, split the data platform by bytes scanned, split the network by transfer. Write the rule down, because the first question every team asks is how their number was computed, and an answer that arrives a week later has already lost the room.

What the number is for

Deciding what to optimise. Effort follows the unit cost that is worst or moving fastest, rather than the largest absolute line, which is usually just the largest product.

Pricing. A feature whose unit cost exceeds what it earns is a margin problem that compounds silently with adoption. Flat-rate pricing on a usage-driven feature is the classic version.

Capacity conversations. "We need 40 percent more capacity because volume grew 40 percent and unit cost is flat" is a request that approves itself. "The bill is going up" is a request that starts an audit.

Detecting regressions. Unit cost is a metric, so it can have a threshold and an alert. A deploy that doubles cost per comparable successful request deserves investigation. Separate a resource regression from an intentional quality improvement or a shift in request mix.

The trap

Optimising unit cost against a shrinking denominator. If orders and cost both fall 20 percent, cost per order stays flat: 0.8 divided by 0.8 is 1. It improves only if cost falls proportionally faster than orders, and that improvement still needs checks for lost demand or service quality. Track the numerator and the denominator on the same chart, always, so the story cannot be told with only half of it.

Self-check

A quarterly bill rises from $100,000 to $140,000. Over the same period completed orders rise from 100,000 to 160,000. A second product line in the same account has flat volume and a bill that rose from $20,000 to $34,000. Of the total, $18,000 sits in an untagged bucket that nobody has attributed.

Work out the unit cost movement for the first product, decide what the second one tells you, say what the untagged bucket does to both conclusions, and then say what you would do if orders and cost had both fallen 20 percent instead. Work it through before reading on.

The first product improved. Unit cost was 100,000 / 100,000 = $1.00 per order and is now 140,000 / 160,000 = $0.875, a fall of 0.125 / 1.00 = 12.5 percent. Note which way the total moved while that happened: the bill rose 40 percent, so anyone arguing from the total alone would report this efficiency gain as a cost problem, which is the failure the page opens with.

The second product is the real finding and it is the one a total would hide. Volume is flat and spend rose 34,000 / 20,000 = 1.7, so unit cost rose 70 percent with nothing to show for it. Put the two together and the aggregate bill's 40 percent rise is a blend of an improvement and a regression, and the blanket instruction to cut costs that usually follows would land on the team that improved. This is what having a denominator per product buys, and it is a different thing from having one for the company.

The untagged bucket constrains both conclusions and the honest response is to say by how much. Eighteen thousand against a $174,000 total is about 10 percent unattributed, so the first product's $0.875 could be understated by up to roughly 18,000 / 160,000 ≈ $0.11 per order if all of it belonged there, which would erase the improvement. So the correct statement is that unit cost fell 12.5 percent with 10 percent of spend unattributed, not that it fell 12.5 percent. Keeping the unattributed category explicit rather than spreading it by a guess is what makes that statement possible, and reducing it is the highest-value attribution work available.

On the shrinking case, the arithmetic is the trap the page names: 0.8 / 0.8 = 1, so unit cost is exactly flat and nothing improved. What you would do is stop reading it as a cost story at all. A 20 percent fall in orders is a demand or quality problem that happens to have reduced the bill, and the cost chart is reporting it as neutral. This is why the numerator and the denominator belong on the same chart, always, so that the story cannot be told with only half of it.

Next: napkin math is where the per-unit resource figures come from, and platform as a product works a platform team's own case through the same arithmetic.

Sources: FinOps unit economics.

Cloud cost allocation works the numerator through a reconciled bill, shared-cost split and explicit unknown bucket before any per-unit comparison.

Cloud rightsizing tests a lower-cost resource choice against workload peaks, failure headroom and the distinction between an estimated reduction and the actual bill.

RELATED CONCEPTS
PRACTICE THIS IN REAL QUESTIONS