Measuring cloud efficiency beyond the monthly bill

Choose a denominator that reflects useful work

The FinOps Foundation describes unit economics as connecting technology spend with the value it produces. That shifts the discussion from the size of the bill to the relationship between spending and business activity. See the FinOps Foundation’s unit economics guidance.

Our recommendation is to begin with a unit the service owner understands: a completed order, a processed claim or an accepted document review. Counting raw API calls may be useful to engineering, but it can reward retries or unnecessary activity rather than useful work.

Use a simple calculation before a complex dashboard

Illustrative example: a service costs $12,000 in one month and completes 60,000 valid transactions. Its cost is $0.20 per transaction. The following month costs $13,500 and completes 90,000 valid transactions, or $0.15 each. Total spend rose 12.5%, while unit cost fell 25%. These are hypothetical figures, not Catalyst47 client results.

That calculation is only comparable if the service scope and accounting rules remain consistent. Check whether support costs moved elsewhere, whether transaction complexity changed or whether service quality deteriorated. A lower unit cost achieved by rejecting difficult cases is not necessarily an improvement.

Agree the measurement rules

• Cost boundary: which compute, storage, software and support costs are included?
• Activity boundary: what counts as a completed and valid unit of work?
• Allocation: how are shared platform costs assigned, and what remains unallocated?
• Time period: are cost and activity measured over matching periods?
• Quality guardrails: which error, latency or availability measures must remain acceptable?

Investigate changes before taking action

When the metric worsens, separate demand changes from architectural changes and price changes. A new customer segment might require more processing. A release might introduce repeated database queries. A temporary migration might require two environments. Each calls for a different response.

Create an action record containing the proposed change, its owner, expected operational effect and validation date. Do not mark a recommendation as a saving until the change is in place and the comparison accounts for business activity.

Use unit economics to support a decision

For a GenAI workflow, tokens are an engineering input; an accepted, correctly reviewed output is closer to a business result. Include the human correction step when deciding whether the workflow is efficient.

A useful review brings finance, product and engineering together around one question: are we delivering the required outcome more efficiently without weakening service quality? A small set of agreed metrics can answer that question better than a large dashboard with disputed definitions.