Why cloud savings remain theoretical — and how to actually realise them

Cloud platforms can surface hundreds of optimisation recommendations. The difficult part is rarely finding another recommendation. It is turning the right opportunities into approved actions, implemented changes and measurable financial outcomes.

Finding savings is only the beginning

Most organisations with meaningful cloud estates already have access to cost information.

AWS, Azure and Google Cloud provide native cost-management capabilities. Many organisations also use specialist FinOps platforms. Engineering teams receive rightsizing recommendations, commitment recommendations, idle-resource alerts and other optimisation signals.

Yet a recurring problem remains: a recommendation appears on a dashboard, everyone agrees that it looks sensible — and months later the cost is still there.

The gap between identified opportunity and realised value is where much of the practical challenge of FinOps sits.

An estimated saving is not a saving.
A recommendation is not a saving.
Even an approved optimisation is not a saving.

Value is realised only when an appropriate action is implemented and its financial impact can be demonstrated.

Why good recommendations stall

There are usually legitimate reasons.

An apparently oversized compute resource may support a critical workload with seasonal peaks. An unused volume may be retained because nobody is confident that it can safely be deleted. A commitment may look attractive financially but introduce risk if demand is uncertain.

Then there are organisational barriers.

Who owns the decision? Who has authority to approve it? Which Engineering team has to implement it? Does the change compete with product work? What happens if the change affects performance or reliability?

Finance may see an obvious saving while Engineering sees operational risk. Both perspectives can be valid.

The role of FinOps is therefore not simply to generate recommendations. It is to create the context and collaboration required to make good decisions.

From opportunity to execution

A useful way to manage optimisation is as a value lifecycle:

IdentifyValidateApproveExecuteMeasure

Identify the opportunity using billing data, utilisation information, cloud-native recommendations, architecture knowledge and other relevant signals.

Validate whether the opportunity is technically and financially credible. Understand dependencies, constraints, expected impact and risk.

Approve the action with the appropriate owner and stakeholder.

Execute the change through the team responsible for the workload.

Measure the resulting financial impact against an agreed methodology.

Each stage matters. Without validation, organisations risk chasing theoretical savings. Without ownership, opportunities become nobody's priority. Without execution, recommendations remain recommendations. Without measurement, Finance cannot confidently distinguish claimed savings from realised value.

Make ownership explicit

One of the simplest improvements is to stop treating optimisation opportunities as anonymous entries in a report.

Every material opportunity should have an owner. That does not necessarily mean the FinOps team.

A database optimisation might belong to Database Engineering. Rightsizing may sit with a product or platform team. Commitment decisions may require Finance, FinOps and Technology leadership.

The FinOps function facilitates the process and provides financial context, but accountability for cloud usage increasingly needs to sit close to the teams making architectural and consumption decisions.

This changes the conversation from:

"There is a $20,000 recommendation."

to:

"There is a validated opportunity, this team owns the decision, these are the dependencies, and this is the next action."

That is a much more useful management construct.

Prioritise value, not recommendation count

A backlog containing 500 recommendations is not necessarily evidence of a mature FinOps capability. It can be evidence that nobody knows what to do next.

Opportunities should be prioritised according to factors such as financial impact, confidence, implementation effort, risk and dependencies.

A relatively modest opportunity that can be safely implemented this week may be more valuable than a much larger theoretical saving requiring months of architectural work.

The goal is not to maximise the number of recommendations identified. The goal is to improve the rate at which credible opportunities become business value.

Measure what was actually achieved

Execution also changes how savings should be discussed.

Simply comparing last month's bill with this month's bill can be misleading.

Cloud spend may rise because customer demand increased, a new product launched or additional workloads moved to cloud. An optimisation can create genuine savings while the total bill still increases.

For material initiatives, organisations therefore need an agreed way to distinguish the financial effect of the optimisation from unrelated changes in consumption.

That may include a baseline, defined scope, measurement period, attribution rules and relevant adjustments for changing business demand.

The sophistication required should be proportionate to the decision and the value involved. But the principle is important: realised savings should represent value attributable to an implemented action — not simply movement in the total cloud bill.

The execution gap is a FinOps opportunity

The next phase of FinOps for many organisations is not another dashboard.

It is connecting financial visibility to the operating mechanisms required to act: opportunity → decision → ownership → execution → measurement.

Cloud cost tools remain important. They provide much of the data and intelligence required to understand consumption.

But financial outcomes happen outside the dashboard. They happen when Finance, Engineering and Technology make informed decisions together — and when those decisions are actually implemented.

That is how theoretical cloud savings become measurable business value.