A platform team spent four months cutting the cost of their ingestion pipeline. They moved to a smaller instance family, added compression, and rewrote the hottest query. When the quarterly review came round, the CFO opened the slide, saw that cloud spend had gone from 610,000 US dollars a month to 655,000, and asked what the engineering effort had achieved. Nobody in the room had a number that answered him.

They had one, they just had not built it. Transaction volume over the same period had grown 68 percent. Cost per thousand transactions had fallen from 11.05 US dollars to 7.35, a 33 percent improvement, which is a very good quarter by any standard. Total spend went up and efficiency went up at the same time, and without a unit metric there was no language in the room capable of saying both things at once. That is the whole point of this capability.

What a unit metric actually is

A unit metric is a division. Cost on the top, a count of something the business cares about on the bottom, both measured over the same period. Cost per customer, cost per transaction, cost per active user, cost per ride, cost per case resolved. The top half is called the numerator and comes from your billing data. The bottom half is called the denominator and comes from the business, which is the reason this capability is harder than it looks: half the inputs are not in the cloud console.

The FinOps Foundation places Unit Economics in the Quantify Business Value domain, and describes it as bringing together what an organisation spends on technology and the value that spending creates. The framing I find most useful with engineering teams is narrower: a unit metric is the only way an engineer can demonstrate that a design decision improved the business, in a form the business already understands. Absolute spend cannot do that, because absolute spend moves when demand moves and nobody can separate the two by looking at it.

Two related terms come up constantly and are worth pinning down now. Cost to produce is what you spend building and running the thing before anyone pays for it, including development and test environments. Cost to serve is what you spend delivering it to a paying customer once it is live. They behave differently, they are owned by different people, and mixing them in one metric produces a number that moves for reasons nobody can explain. Keep them separate until you have a specific reason not to.

Two kinds of unit metric, and why the difference matters

The Foundation sorts unit metrics into two categories, and getting this distinction right early saves an enormous amount of argument later.

Resource efficiency unit metrics use a technical denominator: cost per GB stored, cost per GB transferred, cost per virtual CPU hour, cost per seat used, cost per token. Engineers can compute these from data they already own, they move when engineering changes something, and they need nobody outside the technology organisation to agree on a definition. This is why almost every practice starts here, and starting here is correct.

Business unit metrics use a business denominator: cost per tenant, cost per transaction, cost to serve, cost per case resolved. These are the ones leadership and product actually make decisions with, because they connect to pricing, packaging and margin. They are also harder, because the denominator lives in a product analytics system or a billing platform somebody else owns, and because getting three departments to agree on what counts as an active customer is a political exercise rather than a technical one.

The Foundation treats a working business unit metric as an indicator of higher maturity, and that matches what I see. The mistake is treating the two as a sequence where you must finish one before touching the other. Run a resource efficiency metric to give engineering something controllable to move this quarter, and start the conversation about the business denominator in parallel, because the conversation is the long pole and it does not need the data to begin.

flowchart LR
  A[Billing data by product] --> B[Apply allocation rules]
  B --> C[Numerator, cost for the period]
  D[Product analytics or billing system] --> E[Agree the counting rule]
  E --> F[Denominator, units for the period]
  C --> G[Unit metric]
  F --> G
  G --> H[Trend over time within one product]
  H --> I[Decision on pricing, architecture or roadmap]

Choosing your first metric

There is no metric that suits every business, and the Foundation is blunt that there is most likely no single metric to rule them all. What there is, is a test. A good first unit metric satisfies four conditions: the denominator is already counted somewhere for another reason, the number moves when engineering changes something, somebody outside engineering recognises the unit without an explanation, and one person can be named as the owner of its definition. If a candidate metric fails any of those, pick a different one rather than trying to build the missing piece first.

That third condition does more work than it appears to. Cost per vCPU hour passes the first two tests easily and fails the third completely, which is why it is useful inside a platform team and useless in a board pack. Cost per transaction usually passes all four, which is why it is the most common starting point in transactional businesses.

The table below is a starting menu rather than a recommendation. The figures are illustrative and chosen to show the order of magnitude these numbers land at, because the first question anyone asks is whether their own number looks sane, and there is no public benchmark that will tell them.

Values are illustrative and sized to be plausible rather than authoritative. Metric names and the two category definitions follow the FinOps Foundation Unit Economics capability, checked in July 2026.

Which costs go in the numerator

This is where most unit economics work stalls, and it stalls on a question that has no correct answer, only a documented one. Do you use list price or your negotiated rate? Do you include the amortised portion of a three year commitment, meaning the upfront payment spread evenly across the term rather than charged in the month you paid it? Do you allocate shared costs such as the observability platform, the network backbone and the security tooling? Do you include support charges? Do you include the salaries of the team that runs the thing?

My position, and it is a position rather than a rule: use amortised effective cost including discounts, allocate shared costs only when a defensible driver exists, and leave people cost out until the metric is trusted. Effective cost is what the workload really costs your organisation, so a rightsizing decision and a commitment decision both show up in the same number, which is what you want. Excluding labour at the start is a practical concession rather than a principled one, because the moment a unit metric contains headcount it becomes a conversation about headcount and stops being a conversation about architecture.

Whatever you choose, write it down in one paragraph and version it. The Foundation lists documenting metric definitions, assumptions and cost inclusions as a core practitioner activity for exactly this reason. A unit metric whose definition changed silently between two quarters is worse than no metric at all, because somebody will make a decision on the difference.

If you run more than one cloud, or cloud plus SaaS, normalising the numerator is real work and worth doing on a standard rather than a bespoke schema. FOCUS, the FinOps Open Cost and Usage Specification, is the vendor neutral billing schema built for this, and version 1.4 was ratified by the FOCUS Steering Committee on 4 June 2026. It matters here specifically because a unit metric built on one provider’s native export has to be rebuilt from scratch when a workload moves, and one built on FOCUS does not.

The trap of measuring the wrong denominator

The Foundation gives a worked failure that is worth repeating because it catches good teams. Suppose you store customer data and you decide to measure cost per GB stored. An engineer then finds a better compression scheme and cuts your storage requirement by 30 percent. Your storage bill drops. Your cost per GB stored does not move at all, because both halves of the fraction fell together. The metric reports that nothing happened.

Measure cost per stored item instead, and the same change shows as a 30 percent improvement, because the item count is fixed by customer behaviour and only the cost side moved. The rule this generalises to: your denominator must be something the business does, not something your infrastructure does. Anything an engineer can change is a bad denominator, precisely because it will absorb the improvement you are trying to show.

The same failure appears with cost per instance hour, cost per container, and cost per node, all of which are popular and all of which go quiet exactly when someone does good work. Cost per request, cost per order and cost per customer do not have this property. If you can only remember one thing from this part, make it this one, because it is the difference between a metric that funds further investment and a metric that quietly kills it.

How cost per customer changes the conversation

Cost per customer, or cost per tenant, is the metric that most often turns a FinOps practice from a reporting function into a decision making one, because it lands directly on pricing. Once you can put cloud cost next to revenue for the same cohort, you have contribution margin, meaning the gross profit from serving one more customer of that type. That number changes product decisions in a way that no efficiency chart ever does.

The pattern below is common enough that you should expect to find some version of it. The enterprise tier looks expensive in absolute terms and is comfortably the healthiest on margin. The self serve tier looks cheap per customer and is the one destroying gross margin, usually because a small number of heavy users on an unmetered plan consume like enterprise accounts while paying like hobbyists.

Illustrative cohort economics for a multi tenant SaaS product. Note the free trial line: 74,100 US dollars a month of cloud cost with no revenue attached, which is a marketing expense and should be reported as one rather than buried in cost of goods sold.

Crawl, walk, run without stalling

The Foundation’s maturity model for this capability is straightforward. Crawl is cloud cost only, mostly technical metrics, direct variable costs, low organisational adoption. Walk brings in SaaS, licences and other technology categories, uses outcome data more often, and gets leaders referencing stable business metrics in their routines. Run has defined unit metrics for every operational scope, fully loaded costs including labour and on premises, metrics at several levels of granularity, and unit economics shaping build versus buy and workload placement decisions before they are made rather than after.

Most practices stall between crawl and walk, and the reason is almost always the same: they try to make the crawl metric perfect instead of shipping it. The Foundation’s advice on this is unusually direct, warning against letting perfect be the enemy of good and encouraging you to publish a draft model with known deficiencies. I would go further. Publish the number with the caveats printed next to it, in the same slide, in the same font size. A metric with visible flaws generates corrections from the people who own the data, which is exactly the collaboration you were trying to start.

The second stall is metric proliferation. A practice that defines fourteen unit metrics in its first year has fourteen definitions to maintain, no shared vocabulary, and no metric anyone recognises. The Foundation notes that unit metrics should be maintained centrally, treated as dynamic, and retired when they stop driving behaviour. Retiring metrics is the part everybody skips. If a number has not changed a decision in two quarters, remove it from the pack.

flowchart TD
  A[Pick one product and one period] --> B{Can you count the units already}
  B -->|No| C[Pick a different denominator this quarter]
  B -->|Yes| D[Attribute cost by usage where possible]
  D --> E{Attributed share above 60 percent}
  E -->|No| F[Improve tagging, spread the rest evenly, publish anyway]
  E -->|Yes| G[Publish the metric with its definition]
  F --> G
  G --> H[Review at a fixed cadence for two quarters]
  H --> I{Did it change a decision}
  I -->|No| J[Change the metric or retire it]
  I -->|Yes| K[Add fully loaded costs and a second scope]

Ship one metric, for one product, with a written definition

Here is the recommendation for this part, stated plainly. Pick one product, not the whole estate. Pick one denominator that somebody already counts for another reason, and check it against the four tests: already counted, moves with engineering, recognised outside engineering, has a named owner. Build the numerator from amortised effective cost, attribute by usage as far as your tagging allows, spread the remainder evenly, and publish the number this month in a spreadsheet with its definition printed beside it. Do not wait for a tool and do not wait for the allocation to be clean.

Then review it at a fixed cadence for two quarters and watch whether it changes anything. If it does, add cohorts, add a second scope, and start bringing in SaaS and licence costs. If it does not, the metric is wrong and you should change it rather than defend it. One imperfect metric that a product owner argues about beats six clean ones nobody opens, and that is true at every maturity level I have worked at.

Part 11 turns from measuring value to reducing cost, starting with rightsizing compute, which is the first optimisation lever most teams reach for and the one most often applied to the wrong workloads. The allocation groundwork sits in Part 5, the accountability model in Part 6, and every part so far is indexed on the Cloud FinOps guide.

One thing to do this week: take last month’s cloud cost for your largest product, ask the product owner how many customers or transactions it served, and divide. Then ask three people what that number should be. The spread in their answers is your real maturity score.

References

• Unit Economics capability, FinOps Framework, FinOps Foundation
• Introduction to Cloud Unit Economics, FinOps Foundation Unit Economics Working Group
• FOCUS Specification, version 1.4 ratified 4 June 2026
• Selecting a unit metric to support your business, AWS Cloud Financial Management blog

All monetary figures, cohort splits and percentages in this part are illustrative and chosen to show realistic proportions. Framework wording, capability definitions and the FOCUS version were verified in July 2026 and change over time.

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts