Cost Per Transaction
Infrastructure cost divided by business volume, which reveals efficiency trends that absolute spend conceals.
Absolute cloud spend rising is not a problem if volume is rising faster. Cost per transaction — per order, per user, per API call — is the number that shows whether the system is becoming more or less efficient.
It reframes the conversation productively. "Spend is up 40%" invites a cost-cutting exercise. "Cost per order fell 15% while volume rose 60%" is a demonstration of engineering value, and "cost per order rose 20%" is a specific problem with a specific cause.
It also makes performance work fundable. A latency improvement that reduces instance count has a calculable return; a caching layer that raises hit rate from 95% to 99% divides backend load by five, and that translates directly.
Where the trade is genuinely a trade: lower latency usually costs money — more capacity, more replicas, a CDN, headroom to stay on the flat part of the queueing curve. The right level is set by what latency is worth, which for customer-facing paths can be measured against conversion, and for internal tooling generally cannot.
The prerequisite is attribution: cost allocated to services, teams and features by tagging. Without it, cost per transaction cannot be computed for anything smaller than the whole estate, and nobody can act on it.