Coverage and utilization are diagnostics. They are not savings. You can have high numbers on both and still be worse off than pure On-Demand.
Effective Saving Rate (ESR) is the metric that matters. It measures actual spend under commitments against what you would have paid at On-Demand prices.
Formula: ESR = 1 − (actual cost ÷ on-demand equivalent cost).
Use ESR to pick between combinations, not individual commitments. The optimal mix of RIs, Convertible RIs, and Savings Plans is the one with the highest ESR for your specific usage shape.

How much are you actually saving?

Ask a FinOps practitioner how much their commitments are saving, and you will usually get one of two answers:

“We have 85% coverage across our compute fleet.” “Our RI utilization is over 95%.”

Both sound great. Neither answers the question. Coverage tells you how much of your running fleet is sitting under a commitment. Utilization tells you how much of the commitment is being burned. Neither tells you how many dollars you saved compared to the alternative of paying On-Demand for the same usage.

This is not a nitpick. Coverage and utilization can be high while your actual savings are zero — or negative. Article #02 walks through the cases. This article is about what to use instead.

When the answer is simple

Before the interesting case, the easy one.

If your workload runs 24/7 — a production database, a core controller, an always-on web tier — then maximising coverage does lead to maximum savings. The commitment matches usage every hour, utilization stays near 100%, and the discount rate is the full advertised rate.

But pause on that for a second. If your workload really runs 24/7 with predictable shape and no elasticity, you are using the cloud like a data centre. At which point the honest question is whether the cloud is still the right home for it at all. I have seen large, stable workloads that would genuinely be cheaper to repatriate — and that is a real finding, not a provocation.

For the rest of this article, assume the realistic case: your workloads are elastic.

Elasticity breaks the simple picture

Once you start switching instances off at night, shutting down dev environments on weekends, or auto-scaling during the day, coverage and utilization stop moving in lockstep.

You can push one up at the cost of the other. Buying more commitments lifts coverage but drops utilization (the extra commitments have fewer running instances to match). Cutting back commitments lifts utilization but drops coverage (more of your running usage is now at On-Demand rates).

Which direction is better for your wallet? It depends on prices, discount rates, and the exact shape of your usage. You need a way to score the outcome. Coverage and utilization do not give you that score. ESR does.

The ESR formula

Effective Saving Rate compares what you actually paid to what you would have paid at pure On-Demand rates.

 ESR = 1 − (actual cost under commitments ÷ equivalent On-Demand cost)

That is it. One division, one subtraction.

A supermarket illustration makes the intuition obvious. Which deal saves more: buy 2 get 1 free or buy 3 get 2 free?

 Buy 2 get 1 free:   pay for 2, take home 3
   ESR = 1 − (2 / 3) = 0.333 → 33.3% saved

 Buy 3 get 2 free:   pay for 3, take home 5
   ESR = 1 − (3 / 5) = 0.400 → 40.0% saved

Intuitively, “buy 3 get 2 free” sounds smaller because the free-to-paid ratio looks similar. ESR shows it is the better deal by nearly 7 percentage points. The formula cuts through the cognitive trick and gives you the answer directly.

That is exactly the job it does on cloud commitments: cutting through the coverage/utilization intuition and giving you the real number.

ESR in practice — worked example

Setup:

20 compute instances in the fleet
Dev instances shut down on weekends → average weekly usage is 58%
RI discount rate: 65%
On-Demand price: $0.10/hour per instance
One full week = 168 hours

Actual running hours across the fleet per week:

 20 instances × 168 hours × 58% usage  =  1,948.8 instance-hours/week

Three scenarios, varying coverage:

Scenario	RIs bought	Coverage	Logic
A	18	90%	Aggressive — try to cover most of fleet
B	15	75%	Balanced — cover the weekday baseline
C	12	60%	Conservative — cover only the stable core

For each scenario, compute the actual cost (RI cost + On-Demand cost for anything not covered), the On-Demand equivalent (what the same usage would have cost at pure On-Demand), and ESR.

 ─────────────────────────────────────────────────────────────
 Calculation per scenario (1 week)
 ─────────────────────────────────────────────────────────────

 RI cost per instance per week (paid for all 168 hours regardless):
   $0.10 × (1 − 0.65) × 168 = $5.88 per RI per week

 On-Demand cost per instance-hour:  $0.10
 On-Demand equivalent for 1,948.8 instance-hours:  $194.88
 ─────────────────────────────────────────────────────────────

Scenario	RI cost	RI-covered hours	OD hours leftover	OD cost	Actual total	OD equivalent	ESR
A (90%)	18 × $5.88 = $105.84	~1,754 hrs	~195 hrs	$19.50	$125.34	$194.88	35.7%
B (75%)	15 × $5.88 = $88.20	~1,462 hrs	~487 hrs	$48.70	$136.90	$194.88	29.7%
C (60%)	12 × $5.88 = $70.56	~1,170 hrs	~779 hrs	$77.90	$148.46	$194.88	23.8%

(Numbers are illustrative; RI-covered hours depend on matching behaviour. Treat these as order-of-magnitude.)

The pattern that matters is not the exact cell values — it is the relationship:

Higher coverage does not automatically mean higher ESR. If elasticity is high enough, aggressive coverage tips into over-commitment and ESR collapses.
Lower coverage can beat higher coverage. Scenario B or C can outperform A when the workload off-hours are steep.
Utilization alone is misleading. Scenario C can show high per-commitment utilization but the total ESR is low because too much usage sat at On-Demand.

In my own work, I have seen real fleets where an “aggressive coverage” strategy pushed ESR into the negative — paying more under commitments than pure On-Demand would have cost. Without ESR as the scoreboard, that failure mode is invisible.

Using ESR to find the optimal mix

ESR ranks deals. It does not hand you the best combination of commitments directly. To find the best mix, you calculate ESR across a grid of commitment combinations — varying coverage level, mix of Standard RI vs. Convertible RI vs. Savings Plan, term length — and pick the combination with the highest ESR.

 Illustrative ESR landscape (one workload, 1-year horizon)

           Coverage →
           50%    60%    70%    80%    90%    100%
         ┌──────────────────────────────────────────┐
   All SP│ 18%   21%   23%   22%   19%   13%        │
   Mixed │ 22%   27%   32%   34%  *35%*  30%        │  ← best
   All RI│ 19%   24%   28%   29%   25%   12%        │

 The "Mixed @ 90%" cell is the ESR peak for this workload.

In reality, this grid has more dimensions than two:

Standard RI vs. Convertible RI vs. Savings Plan ratios
1-year vs. 3-year terms
Payment options (All Upfront / Partial / No Upfront)
Per-region, per-instance-family variations
Changing usage shape over the commitment term

At that point you are no longer choosing between three or four options. You are choosing between thousands. A human with a spreadsheet cannot keep up.

This is why automated commitment-management platforms exist — tools like ProsperOps, Zesty, and similar, which continuously recalculate ESR across the combination space and adjust commitments on your behalf. They are not magic; they are just running the same ESR calculation at a scale and cadence you cannot match manually.

This article was inspired by a talk given by Eric Carlin, founder of ProsperOps.

Summary

Coverage and utilization describe the shape of your commitments. ESR measures the result.
ESR = 1 − (actual cost ÷ On-Demand equivalent cost). One formula, one number, comparable across any commitment strategy.
Use ESR to rank combinations — not to judge single commitments in isolation.
Finding the maximum-ESR combination by hand is impractical once the fleet is non-trivial. This is automation territory.

Thanks for reading. If this helped, share it. Questions or topic suggestions — send them through.