Your cloud bill was $500,000 last month. This month, it is $560,000. Spend is up 12%. For Finance, the question seems obvious: what went wrong?
Perhaps nothing did.
The business may have grown. Transaction volumes may have increased. New customers may have been onboarded. More workloads may have moved to the cloud. A new product may have launched.
Or perhaps cloud efficiency really did deteriorate.
The problem is that the bill alone cannot tell you which explanation is true.
One of the most important shifts in FinOps is moving beyond the idea that success means making total cloud spend go down.
Sometimes good FinOps reduces the bill. Sometimes it helps an organisation support significantly more business activity for only a modest increase in cost.
The real question is not simply "how much did we spend?" It is "what did we get for that spend — and how efficiently did we get it?"
A higher bill is not automatically bad news
Consider a digital business spending $500,000 per month on cloud. Six months later, monthly spend reaches $600,000. A 20% increase sounds significant.
Now add one piece of information: over the same period, the number of transactions processed by the platform increased from 10 million to 15 million.
Cloud spend increased 20%. Business activity increased 50%.
The economics now look very different. At 10 million transactions, cloud cost was $0.050 per transaction. At 15 million transactions, it is $0.040 per transaction.
$0.050 → $0.040 per transaction — a 20% fall in unit cost
The organisation is spending more in absolute terms while its cloud cost per transaction has fallen by 20%.
From a budget perspective, the bill increased. From an efficiency perspective, the platform improved. Both statements are true.
That distinction matters.
The opposite can also happen
Now imagine another company. Cloud spend falls from $500,000 to $450,000 per month. At first glance, this appears to be a successful cost reduction.
But during the same period, customer activity falls by 25%.
If the business is doing materially less work, a lower cloud bill may simply reflect lower demand. The organisation could actually have become less efficient even though total spend declined.
This is why lower spend does not automatically mean better FinOps, and higher spend does not automatically mean worse FinOps. The movement in the bill needs context.
Start with the cost drivers
When cloud spend changes materially, the first question should not be "why did the bill go up?" A better question is "what changed?"
There are many legitimate reasons cloud spend can increase:
Customer growth
Transaction growth
New products or features
Increased data volumes
Expansion into new markets
Higher availability or resilience requirements
Migrations from on-premises infrastructure
Security improvements
Increased development activity
There are also less desirable reasons:
Idle resources
Overprovisioning
Poor architecture
Uncontrolled data growth
Inefficient storage
Low commitment utilisation
Unnecessary environments
Weak cost ownership
FinOps should help distinguish between productive growth in spend and economic inefficiency. Those are very different management problems.
Unit economics can make cloud spend meaningful
Where reliable business metrics exist, unit economics can provide valuable context. Instead of looking only at total cloud spend, an organisation might also consider:
Cost per transaction
Cost per order
Cost per active customer
Cost per API request
Cost per workload
Cost per unit of data processed
The appropriate unit depends entirely on the business. A SaaS company may care about cost per customer or tenant. An e-commerce platform may look at cost per order. A payments company may use cost per transaction. A data platform may consider cost per query or data volume processed.
These metrics can connect cloud consumption with the activity creating business value.
But there is an important warning: do not create a unit metric simply because FinOps says you should have one.
If the organisation cannot reliably allocate costs or measure the underlying business activity, a precise-looking unit metric can create false confidence.
Use unit economics when the underlying data is credible. Otherwise, start with the best available demand drivers and improve the model over time.
Growth does not explain everything
There is a risk at the other extreme. If every cloud increase is attributed to "business growth", FinOps becomes impossible to challenge.
Growth needs evidence.
Suppose cloud spend increased by 30%, while the relevant business demand increased by only 5%. That does not automatically prove inefficiency, but it should trigger investigation.
Perhaps the product mix changed. Perhaps a new workload has very different economics. Perhaps resilience requirements increased. Perhaps an architecture change introduced additional cost. Or perhaps the environment genuinely became less efficient.
FinOps should not be used to justify spend. It should make the economics more explainable.
That means understanding the relationship between business activity and cloud consumption rather than automatically treating either growth or cost reduction as good.
What would we have spent without the improvement?
Business growth introduces another challenge.
Imagine a platform costs $400,000 per month. Demand is expected to grow 25%. If cloud cost scaled proportionally, the expected cost might reach approximately $500,000 per month.
But through better resource utilisation, architectural improvements and commercial optimisation, actual spend reaches only $455,000.
The bill still increased by $55,000. Yet compared with the expected cost at the new level of demand, the organisation may have avoided approximately:
$500,000 expected − $455,000 actual = $45,000 avoided per month
This is where a counterfactual becomes useful. Instead of comparing only previous spend versus current spend, you also consider expected spend without improvement versus actual spend.
That does not mean every cloud workload needs a complex financial model. For stable workloads, simple before-and-after comparisons may be perfectly reasonable. But when business demand changes materially, ignoring that change can produce misleading conclusions.
Savings and cost avoidance are not always the same thing
This distinction is particularly important for Finance.
Suppose an optimisation reduces an existing workload from $100,000 to $80,000 per month. That is relatively intuitive: the organisation is now paying less for something it was already consuming.
Now imagine a different situation. A platform is growing rapidly and would reasonably have required an additional $30,000 of monthly infrastructure. Engineering improves the architecture and absorbs the additional demand without that expected increase.
The financial benefit is real. But it may be better described as cost avoidance rather than a direct reduction in the existing bill.
The distinction matters because different organisations treat these benefits differently in budgets, forecasts and financial reporting.
FinOps should make the nature of the value transparent rather than combining every financial benefit into one ambiguous "savings" number.
Commitments can make the bill even harder to interpret
Cloud economics also becomes more complex when commitments and discounts are involved.
An organisation may reduce its effective unit rate by purchasing Reserved Instances, Savings Plans, Committed Use Discounts or similar commercial commitments. That can improve economics. But the organisation has also accepted future consumption risk.
A lower effective rate does not automatically mean the commitment decision was optimal. You also need to understand:
Utilisation
Coverage
Term
Flexibility
Expected demand
Unused commitment exposure
This is another example of why the total bill is an incomplete measure.
FinOps is not simply about paying the lowest possible rate. It is about making economically sound trade-offs between cost, usage, flexibility and risk.
So what should a CFO ask?
When cloud spend rises, the executive conversation should move beyond "why is the bill higher?"
A stronger set of questions is:
What changed in business demand?
Which products, workloads or services drove the increase?
How much of the increase was expected?
Did our unit economics improve or deteriorate?
Were there material changes in architecture, resilience or service scope?
Did our effective cloud rates improve?
What cost would we reasonably have expected without optimisation?
Which increases represent productive investment and which indicate inefficiency?
Those questions create a much more useful discussion than treating every increase as a cost-control failure.
FinOps should make cloud economics explainable
The objective of FinOps is not to force the cloud bill downward every month.
Cloud exists to support the business. If the business grows, launches products, processes more transactions or serves more customers, cloud spend may grow with it.
The challenge is to understand whether that growth in cost is economically justified and increasingly efficient.
Sometimes the right outcome is a smaller bill. Sometimes it is a larger bill with better unit economics. Sometimes it is avoiding an increase that would otherwise have occurred. And sometimes the analysis will reveal genuine inefficiency that needs to be addressed.
The value of FinOps is being able to tell the difference.
Key takeaway. Cloud spend is a financial number. Cloud efficiency is an economic relationship.
Looking at the bill alone cannot tell you whether FinOps is working. You need to understand what changed in the business, what drove consumption, how unit economics evolved and — where relevant — what the organisation would reasonably have spent without optimisation.
So when cloud spend increases, the first question should not be "did FinOps fail?" It should be "did our cloud economics get better or worse?"
Nooven helps organisations connect cloud cost with business context — creating a clearer view of efficiency, financial impact and the value being generated from cloud investment.
