Cloud Cost Optimization ROI: How to Measure It Honestly

The return on a cloud cost optimization program is the realised reduction in spend, measured against a defensible baseline, divided by what the program cost to run. Each part of that sentence hides a way to get the number wrong. This page walks through building the calculation yourself rather than quoting someone else’s benchmark, because the only ROI that matters to your leadership is the one computed from your own bill.

Step 1: fix the baseline

Savings are always relative to something. Pick one of these and state it:

• Run-rate baseline: what the resource would have cost if nothing changed, such as an always-on instance priced at its hourly rate for every hour of the period.
• Pre-change actuals: the same resource’s billed cost in a comparable period before the change.
• Forecast baseline: the budgeted or forecast spend, useful when volume is growing.

Growth breaks the pre-change method. If traffic doubled, a flat bill is an efficiency gain even though nothing went down. For growing workloads, measure against a unit metric such as cost per order or per request; AWS’s Well-Architected cost pillar makes the same point with its design principle to measure overall efficiency, the business output of a workload against the cost of delivering it. See unit economics.

Step 2: separate estimated from realised

A recommendation’s saving is an estimate made before anyone acted. Realised saving is what the bill shows afterwards. Count only realised savings in ROI, and verify that the change actually happened and stayed in place.

ZopNight keeps these apart: a recommendation’s status records what the customer said they did, and a separate resolution state records what was measured against a before-picture captured when the recommendation was raised, so “applied” and “verified” are not conflated. For schedules, ZopNight calculates savings as the 24/7 cost minus the actual cost from time spent running, and when billing data is connected, schedule recommendations are priced from the resource’s billed cost per running hour, which includes negotiated discounts.

Step 3: do not add overlapping levers

Rightsizing a VM and scheduling the same VM each claim a saving on the same hours. Adding both overstates the total. Take the largest applicable saving per resource, not the sum. ZopNight’s recommendation export follows this rule, de-duplicating savings per resource so mutually exclusive levers do not stack.

Step 4: count the program’s cost

• Tool subscriptions and any charges they add.
• Engineering time to review, apply, and verify changes.
• Coordination time in FinOps, finance, and review meetings.
• Risk cost: any incidents or performance regressions caused by a change.

Step 5: compute and present

• Net annualised saving = realised monthly saving x 12 minus annual program cost.
• ROI = net annualised saving / annual program cost.
• Payback period = one-off setup cost / realised monthly saving.

Present realised and pipeline figures separately: “realised to date” from verified changes, and “open estimate” from recommendations not yet acted on. Mixing them is the fastest way to lose credibility with finance.

Value that is not in the formula

Some returns are real but hard to price: budget freed for other projects, fewer end-of-month surprises, and faster answers when leadership asks where spend went. List them next to the number, not inside it.

Related: what cloud cost optimization covers, building your own cost benchmarks, and the FinOps maturity model.