The effective savings rate is the saving from commitment discounts, and depending on the basis negotiated discounts, as a share of what the same usage would have cost without them. It sums up in one number what reservations, Savings Plans and committed use discounts actually deliver, including the commitment that was paid for and not used. It is meaningful only with three statements attached: scope, period and price basis, because the same cost gives different rates on different bases.
How it works
The rate compares two totals over the same period: what the usage would have cost at a reference price, and what it effectively cost, with commitments spread over the usage and the unused part included. FOCUS supplies the columns. ListCost is list unit price times quantity, ContractedCost contracted unit price times quantity, and without negotiated discounts contracted cost equals list cost. EffectiveCost is the cost after all discounts, including the applied share of the commitment. How the cost measures relate is covered in list, billed, effective and amortized cost.
Three sources choose three reference points:
| Source | Formula | What the rate includes |
|---|---|---|
| FOCUS use case library | (ContractedCost − EffectiveCost) / ContractedCost | commitment discounts only, because negotiated prices are already in contracted cost |
| Microsoft's FinOps toolkit | savings against list cost, excluding commitment purchases | negotiated and commitment discounts |
| FinOps Foundation working group | (savings from RIs and Savings Plans − cost of achieving them) / on-demand equivalent | commitment discounts minus effort such as tooling and staff time |
The FinOps Foundation lists the rate under its Rate Optimization capability as the KPI Effective Savings Rate Percentage.
Purchases and unused commitment
Under FOCUS, a commitment purchase intended to cover eligible usage carries an EffectiveCost of zero; its amount appears pro rata on the covered usage rows, and across the purchase and the covered usage EffectiveCost must add up to the billed amount. Whatever finds no usage sits in rows with CommitmentDiscountStatus = Unused: effective cost with no usage behind it. That is why unused commitment lowers the rate, and heavy overcommitment turns it negative. The Foundation's working group reads a negative rate as a premium over the on-demand rate, usually from commitments that are too large or poorly utilised; Microsoft's toolkit names unused commitments as one place to check when savings come out negative. For savings calculations, the ContractedCost and ListCost definitions advise excluding either the purchases or the covered usage so that nothing counts twice; on an accrual basis, the purchases. The use case library's query sums every row, so anyone adopting it unchanged checks in their own export what contracted cost purchase and Unused rows carry.
What moves the rate
The working group breaks the rate down into utilisation, coverage and discount. Four levers move it:
- Coverage: the share of eligible usage running under a commitment; more coverage raises the rate as long as utilisation holds. Both measures are covered in commitment coverage and utilisation.
- Utilisation: the share of the commitment actually used; every unused hour is effective cost with nothing in return.
- Discount depth: term, payment option and how tightly the commitment binds set the discount, as cloud commitment discounts compared by type shows.
- Negotiated prices: they raise only the list-based rate; on a contracted basis they are already in the denominator.
Where the inputs come from
| Source | Reference cost | Effective cost and unused part |
|---|---|---|
| FOCUS | ListCost, ContractedCost | EffectiveCost, unused with CommitmentDiscountStatus = Unused |
| AWS CUR 2.0 | pricing_public_on_demand_cost at public On-Demand rates | reservation_effective_cost and savings_plan_savings_plan_effective_cost per covered line; unused in reservation_unused_amortized_upfront_fee_for_billing_period, reservation_unused_recurring_fee and, for Savings Plans, savings_plan_total_commitment_to_date less savings_plan_used_commitment |
| Azure | ListCost, ContractedCost in the FOCUS export | EffectiveCost; Microsoft documents CommitmentDiscountStatus as currently empty in 1.2-preview |
| Google Cloud | cost_at_list for the list basis, cost with negotiated discounts | cost plus credits with the CUD credits; in the new model for spend-based CUDs, FEE_UTILIZATION_OFFSET offsets the fee and usage is charged at the discounted price |
Which FOCUS columns each provider fills is in FOCUS columns and the providers' mapping.
What it means for your cost
The rate measures the rate levers, not cost as a whole. A usage action can lower it while the invoice falls: downsizing after buying a commitment lowers that commitment's utilisation. In a report it therefore stands next to effective cost, coverage and utilisation, never alone.
Every reported rate states three things. The basis: contracted, list or on-demand equivalent. The scope: the use case library's query takes every row of the period, the working group's example only usage under RIs and Savings Plans plus on-demand spend; ineligible usage in the denominator dilutes the rate. The period: a monthly figure averages hours of over- and under-coverage. A rate per team also depends on how shared commitments are split, as shared cost and how to split it describes.
How a commitment portfolio works towards a better rate is covered in commitment strategy.
Where it goes wrong
- Bases compared. Symptom: two reports give different rates for the same month. Cause: one divides by contracted cost, the other by list cost or the on-demand equivalent.
- Missing prices. Symptom: on Azure, savings and the rate come out suspiciously low or at zero. Cause: Microsoft notes that Cost Management does not include list and contracted prices for every account; the toolkit shows a saving of zero wherever they are missing, until prices are exported.
- Only covered rows counted. Symptom: the rate stays high while utilisation falls. Cause: a filter on covered usage excludes the
Unusedrows, and the unused commitment drops out of the calculation. - The purchase in its month. Symptom: in the month of an upfront payment the rate turns sharply negative. Cause: the calculation used
BilledCostinstead ofEffectiveCost, where the purchase sits in full. - Tiered prices on AWS. Symptom: for tiered services the list basis does not match the price list. Cause: for SKUs with several public On-Demand prices,
pricing_public_on_demand_costshows the equivalent for the highest tier, as on-demand pricing explains. - Cost efficiency instead of savings rate. Symptom: the rate rises after idle resources are cleaned up. Cause: the figure was the cost efficiency of AWS Cost Optimization Hub, 1 minus potential savings divided by optimisable spend, which measures what is still to be had and rises with every recommendation implemented.
Example
V is the contracted cost of eligible usage in the period. A share a of it runs under a commitment with discount r against the contracted price, the commitment is utilised at u, and the negotiated discount against list is n.
| Quantity | Formula |
|---|---|
| Covered usage at the commitment price | a × V × (1 − r) |
| Commitment in the period, used and unused | a × V × (1 − r) / u |
| Uncovered usage | (1 − a) × V |
| Effective cost E | (1 − a) × V + a × V × (1 − r) / u |
| Rate on a contracted basis | (V − E) / V = a × (1 − (1 − r) / u) |
| List cost L | V / (1 − n) |
| Rate on a list basis | (L − E) / L = n + (1 − n) × rate on a contracted basis |
At full utilisation the contracted-basis rate is a × r, coverage times discount. If u falls below 1 − r it turns negative: the commitment then costs more than the covered usage would have cost at the contracted price. The same effective cost gives a list-based rate higher by n × (1 − rate on a contracted basis).
Sources
Read on 2026-10-16. FOCUS use case: determine effective savings rate, use case: effective savings rate by service, columns ListCost, ContractedCost, EffectiveCost and CommitmentDiscountStatus (CC BY 4.0); FinOps Foundation Rate Optimization and How to Calculate Effective Savings Rate (ESR) (CC BY 4.0); Microsoft FinOps toolkit rate optimization report, understanding savings calculations in the FinOps toolkit and FOCUS cost and usage details file schema; AWS CUR 2.0 pricing columns, reservation columns, Savings Plan columns and understanding your cost efficiency metric; Google Cloud standard usage cost data schema.