From identified savings to realised value: how to measure cloud savings properly

A dashboard shows $1.2 million in annual cloud savings opportunities. Six months later, Finance asks a simple question: how much did we actually save?

Suddenly, the answer is less obvious.

The optimisation tool still shows potential savings. The cloud bill has moved. Some recommendations were implemented, others were rejected, and business demand changed during the period.

Several teams may now have different answers to the same question.

This is where savings measurement becomes more than reporting.

If an organisation wants to claim that an optimisation created financial value, it needs to establish what changed, what would otherwise have happened, and how much of the resulting difference can reasonably be attributed to the action taken.

In other words, it needs a measurement methodology.

Start with the action, not the bill

The easiest way to measure cloud savings is often the wrong one:

Previous bill − current bill = savings

The problem is that the cloud bill moves for many reasons.

Demand changes. Products launch. Workloads migrate. Provider prices change. Commitments begin or expire. Resources are decommissioned. Architectures evolve.

Instead of starting with the total bill, start with the specific action that is expected to create value. For example:

• A compute fleet is rightsized.

• A development environment is scheduled to shut down overnight.

• Unused storage is removed.

• A commitment is purchased.

• An application is redesigned to consume fewer resources.

Each action creates a different economic effect. The measurement should follow that effect.

The first question therefore becomes: what exactly changed, and which cost should that change affect? That creates the measurement boundary.

Define the baseline before implementation

A baseline is the reference point against which the outcome will be measured.

For a stable workload, this can be straightforward. Suppose a group of resources costs $50,000 per month. After rightsizing, equivalent resources cost $40,000 per month. If usage, pricing and workload requirements remain comparable, the financial impact is relatively easy to demonstrate.

But baselines become less reliable when conditions change. A representative baseline therefore needs to consider several elements.

Baseline periodWhich period best represents the environment before the change? Thirty days may work for a stable workload. A seasonal business may require a longer or comparable historical period.

ScopeWhich accounts, subscriptions, projects, services or resources are included?

Usage conditionsWas the workload operating at a normal level during the baseline period?

Pricing conditionsWhich discounts, commitments, credits or negotiated rates applied?

Business contextWere there unusual events, migrations, launches or other changes that make the period unrepresentative?

The objective is not to manufacture a perfect baseline. It is to create one that is reasonable, transparent and repeatable.

Decide how demand will be treated

For some workloads, cost is relatively stable. For others, it changes materially with business activity.

Imagine a platform costing $100,000 per month before optimisation. After a technical change, monthly cost is $105,000. A simple before-and-after comparison suggests the optimisation failed.

But transaction volume increased 30% during the same period. If the previous environment would reasonably have cost $130,000 at the new level of demand, the economics are very different. The relevant comparison may therefore be:

$130,000 expected at current demand − $105,000 actual optimised cost = $25,000 monthly economic benefit

Not every workload needs demand normalisation. But where cost is strongly driven by business volume, the measurement methodology should define which demand driver matters and how material changes will be handled.

Otherwise, growth can obscure genuine efficiency improvements — or be used too easily to explain away inefficiency.

Define the counterfactual

Savings ultimately depend on a comparison. The most useful question is often: what would we reasonably have spent if we had not taken this action? That is the counterfactual.

For a deleted idle resource, the answer may simply be its expected ongoing cost. For rightsizing, it may be the expected cost of continuing with the previous configuration. For scheduling, it may be the cost of running the environment under its previous operating hours. For an architectural change, the counterfactual may require modelling what the previous architecture would have cost at comparable demand.

The more assumptions involved, the more important it becomes to document them.

A counterfactual should not be designed to maximise the savings number. It should represent a credible view of what would otherwise have happened.

Different optimisation types need different calculations

A consistent methodology does not mean applying one formula to everything.

RightsizingCompare the cost of the previous configuration with the optimised configuration under comparable usage and pricing conditions.

Resource removalMeasure the cost that would reasonably have continued if the unnecessary resource had remained active.

SchedulingCompare the previous runtime pattern with the new one, accounting for actual required operating hours.

Storage optimisationMeasure the impact of deletion, retention changes or movement between appropriate storage tiers.

CommitmentsCompare effective economics with and without the commitment while accounting for utilisation, coverage, term and unused commitment risk.

Architectural optimisationCompare the new architecture with an agreed counterfactual for the previous design at an equivalent level of demand.

The principles remain consistent. The calculation reflects the economics of the action.

Attribution prevents savings from becoming fiction

Suppose cloud spend decreases by $100,000 in one month. During the same period:

• Engineering rightsizes several workloads

• A legacy product is retired

• Customer demand falls

• A provider discount changes

• A commitment starts applying

How much of the $100,000 reduction came from the optimisation programme? Without attribution rules, almost any answer could be defended.

A savings methodology should therefore distinguish between:

Optimisation-driven changesActions intentionally taken to improve cloud economics.

Business-driven changesFor example, a product closure or lower customer activity.

Commercial changesProvider pricing, negotiated discounts or credits.

Structural changesMigrations, architecture changes or changes in service scope.

The objective is not forensic accounting for every cent. It is to avoid claiming financial value that the optimisation did not actually create.

Watch for overlapping savings

This is one of the easiest ways to overstate an optimisation portfolio.

Imagine a workload has $100,000 potential annual rightsizing savings and $70,000 potential commitment savings. It may be tempting to report $170,000 total opportunity.

But the commitment estimate may have been calculated using the original resource footprint. Once the workload is rightsized, there is less consumption to commit against. The opportunities overlap.

Similar interactions can occur between:

• Rightsizing and scheduling

• Deletion and commitments

• Architecture changes and resource optimisation

• Migration and decommissioning

Savings should therefore be evaluated in the sequence in which the actions affect the underlying cost base. Otherwise, individually valid recommendations can produce an unrealistic total.

Separate gross savings from net economic value

Cloud cost reduction is not always free to implement.

Suppose an architectural optimisation can reduce annual cloud cost by $400,000 but requires $150,000 of engineering effort.

The gross cloud saving is still $400,000. But leadership may also want to understand:

Net first-year value: $250,000

and the expected payback period.

For small operational changes, this level of analysis may be unnecessary. For material engineering initiatives, it can change prioritisation completely.

A $100,000 saving requiring almost no effort may deserve attention before a $400,000 saving requiring months of engineering work.

Savings measurement should therefore support the business decision — not simply produce the largest possible number.

Make the number traceable

If Finance challenges a realised savings figure six months later, the organisation should be able to explain where it came from. For material opportunities, there should be a clear trail:

Source cost & usage dataOptimisation actionAgreed baselineAssumptions & adjustmentsImplemented changeMeasured financial impact

This traceability matters as the programme scales. Without it, realised savings can become a collection of numbers copied between spreadsheets and presentations, with increasingly unclear origins.

A defensible number should be reproducible.

Agree the rules before seeing the result

This may be the most important principle.

Do not wait until after implementation to decide how savings should be calculated. That is when disagreements begin.

Finance selects one baseline. Engineering remembers another. The optimisation tool continues showing its original estimate. The cloud provider reports a different cost movement. Everyone has a number.

For material opportunities, agree the measurement approach before execution:

• Baseline and baseline period

• Scope

• Measurement period

• Relevant demand drivers

• Normalisation rules

• Pricing and commitment treatment

• Attribution rules

• Treatment of overlapping opportunities

• Evidence required to validate the result

The methodology should be proportionate. Deleting a forgotten test resource does not require a financial model. A multi-million-dollar optimisation programme does.

A smaller number can be more valuable

There is often pressure to report the largest savings figure possible. That is short-sighted.

A $2 million "potential savings" number that nobody can defend is less valuable than $900,000 of clearly evidenced financial impact.

The purpose of savings measurement is not to make FinOps look successful. It is to create confidence in the value being reported.

Finance should be able to understand the assumptions. Engineering should recognise the actions. Technology leadership should understand the trade-offs. And if the calculation is challenged, the evidence should still hold.

That is when cloud savings move from a dashboard estimate to a business outcome.

Key takeaway. A savings number is only as credible as the methodology behind it.

For material cloud optimisations, define the baseline, measurement boundary, counterfactual, attribution rules and relevant adjustments before the result is known. Then preserve the evidence linking the action to the financial outcome.

The goal is not the largest possible savings number. It is a number the organisation can trust.

Nooven helps organisations establish credible savings measurement from the outset — defining baselines and measurement rules, validating financial impact and creating traceability from cloud optimisation actions to measurable business outcomes.