.png)
Key takeaways
1
Effective Savings Rate measures the net ROI of commitment discounts relative to what the same in-scope usage would have cost at On-Demand rates. It combines coverage, utilization, discount depth, and the defined costs of achieving savings.
2
The latest ProsperOps AWS compute benchmark reports a 15% median ESR, 30% at the 75th percentile, and 47% at the 98th percentile for 2024 data.
3
High coverage does not guarantee strong savings. Weak utilization or a poor commitment mix can lower ESR even when most eligible usage is covered.
4
ESR requires a consistent reporting scope. Keep the time period, accounts, services, ODE method, amortization approach, and cost treatment consistent.
5
Improve ESR by fixing waste before chasing coverage. Validate underutilization and upcoming workload changes before adding commitments.
Effective Savings Rate, or ESR, turns cloud commitment performance into a financial outcome. Instead of reporting coverage or utilization alone, it shows how much value your discount strategy creates against an On-Demand baseline after accounting for the defined costs required to achieve those savings.
With a consistent scope, FinOps teams can benchmark performance, explain monthly movement, and decide whether to retain, reduce, replace, or selectively add commitment coverage.
The FinOps Foundation Rate Optimization capability defines ESR as a return-on-investment metric for commitment discounts. Its calculation can include the cost of a cloud-management platform, service, internal time, tooling, or other defined costs required to achieve the savings.
A high-coverage portfolio can still underperform when commitments sit unused, discount depth is weak, or the program is expensive to operate. ESR converts those inputs into a financial outcome that can be tracked consistently over time.
Define your ESR scope first
Record the reporting month, cloud accounts, included services, eligible discount instruments, ODE method, amortization approach, and which costs to achieve savings are included. Also document exclusions such as enterprise discounts, credits, taxes, platform fees, or internal labor. Two ESR values are comparable only when their scopes are comparable.
With a consistent scope, FinOps teams can benchmark performance, explain monthly movement, and decide whether to retain, reduce, replace, or selectively add commitment coverage.
Short answer
Effective Savings Rate is the net percentage you save on in-scope cloud usage compared with its On-Demand Equivalent cost. The FinOps Foundation ESR playbook calculates ESR from commitment savings minus the defined cost to achieve those savings, divided by ODE spend. If $150,000 of gross savings costs $10,000 to achieve on $500,000 of ODE spend, ESR is 28%.What Effective Savings Rate measures
Coverage tells you how much eligible usage receives a commitment discount. Utilization tells you how much purchased commitment is consumed. Both are useful, but neither tells finance whether the overall strategy produced a strong net return.The FinOps Foundation Rate Optimization capability defines ESR as a return-on-investment metric for commitment discounts. Its calculation can include the cost of a cloud-management platform, service, internal time, tooling, or other defined costs required to achieve the savings.
A high-coverage portfolio can still underperform when commitments sit unused, discount depth is weak, or the program is expensive to operate. ESR converts those inputs into a financial outcome that can be tracked consistently over time.
How to calculate Effective Savings Rate
Keep the scope, period, and cost basis identical in the numerator and denominator.Define your ESR scope first
Record the reporting month, cloud accounts, included services, eligible discount instruments, ODE method, amortization approach, and which costs to achieve savings are included. Also document exclusions such as enterprise discounts, credits, taxes, platform fees, or internal labor. Two ESR values are comparable only when their scopes are comparable.
Formula
ESR = (Commitment savings - Cost to achieve savings) / On-Demand Equivalent spend
If your actual spend already includes the defined costs of achieving savings, you can also use:
ESR = 1 - (Net actual spend / On-Demand Equivalent spend)
Worked example
Assume a SaaS company has $500,000 in monthly ODE compute spend. Its discounted cloud bill is $350,000, generating $150,000 in gross commitment savings. It spends another $10,000 on the tooling or service used to achieve those savings.| Input | Value |
|---|---|
| On-Demand Equivalent spend | $500,000 |
| Gross commitment savings | $150,000 |
| Cost to achieve savings | $10,000 |
| Net savings | $140,000 |
| Effective Savings Rate | 28% |
($150,000 – $10,000) / $500,000 = 28%
Annualized, this illustrative example produces $1.68 million in net savings on $6 million of ODE spend. If you change the treatment of the $10,000 management cost from one month to the next, the ESR trend becomes misleading.
Annualized, this illustrative example produces $1.68 million in net savings on $6 million of ODE spend. If you change the treatment of the $10,000 management cost from one month to the next, the ESR trend becomes misleading.
Build ESR from cloud billing data
The formula is portable, but provider billing models differ.| Provider | Practical data approach | Caveat |
|---|---|---|
| AWS |
Use Cost and Usage data, APIs, or commitment reports. AWS Data Exports documentation defines pricing/publicOnDemandCost for applicable line items.
|
Cost Explorer alone does not expose every ODE input in the ESR playbook. |
| Azure | Use Microsoft Cost Management cost details or exports to build a documented Pay-As-You-Go baseline. | Field availability depends on agreement type. |
| Google Cloud | Use Cloud Billing exports to BigQuery and current list-price and effective-price fields. |
Define ODE explicitly rather than assuming an on_demand_cost field.
|
Also Read- Microsoft cost Management cost details and Cloud Billing exports to BigQuery.
Collect values from the Savings Plans Utilization, Reservations Utilization, and Savings Plans Coverage reports, or equivalent AWS CLI/API data. Use them to determine Savings Plan ODE and savings, RI ODE and savings, remaining On-Demand spend, and your defined cost to achieve savings. Then calculate one monthly compute ESR.
For deeper AWS analysis, use Cost Explorer alongside a consistent amortized cost view.
AWS implementation
For a monthly AWS compute ESR, choose a full calendar month and a consistent compute scope. The FinOps Foundation playbook uses EC2, Fargate, and Lambda for Savings Plans inputs and EC2 for Reserved Instance inputs.Collect values from the Savings Plans Utilization, Reservations Utilization, and Savings Plans Coverage reports, or equivalent AWS CLI/API data. Use them to determine Savings Plan ODE and savings, RI ODE and savings, remaining On-Demand spend, and your defined cost to achieve savings. Then calculate one monthly compute ESR.
For deeper AWS analysis, use Cost Explorer alongside a consistent amortized cost view.
Current ESR benchmarks
ProsperOps’ current AWS compute benchmark reports the following results. The ProsperOps 2025 Rate Optimization Insights report analyzed approximately $3 billion in AWS compute usage using 2024 data.| Percentile | 2023 ESR | 2024 ESR |
|---|---|---|
| Minimum observed | -9% | -29% |
| 25th percentile | 0% | 0% |
| Median | 0% | 15% |
| 75th percentile | 23% | 30% |
| 98th percentile | 46% | 47% |
RI and Savings Plan adoption increased from 45% to 64%, while median coverage rose from 28% to 55%.
Benchmark methodology note: This cohort covers AWS compute, with EC2 representing about 89% of surveyed compute usage, and scopes ESR to RI and Savings Plan savings. Do not directly compare it with an all-service, multi-cloud, EDP-inclusive, or tooling-cost-inclusive ESR without normalizing the scope.
Benchmark methodology note: This cohort covers AWS compute, with EC2 representing about 89% of surveyed compute usage, and scopes ESR to RI and Savings Plan savings. Do not directly compare it with an all-service, multi-cloud, EDP-inclusive, or tooling-cost-inclusive ESR without normalizing the scope.
Why high coverage can still mean low ESR
A high-coverage portfolio can still underperform when purchased commitments are underutilized, commitment costs continue after workload demand falls, or the discount mix produces less net savings than expected. Coverage tells you how much usage receives a benefit, but ESR tells you whether the complete financial outcome was worthwhile.
Decision rule:
Never raise coverage simply to improve a coverage KPI. First confirm that existing commitments are being used efficiently and that the next baseline is stable enough to justify additional exposure.
What changed this month?
A monthly ESR number is more useful when you can explain why it moved. Compare the same scope with the prior month, then check:
1
ODE movement: Did workload volume, instance mix, region, or architecture change?
2
Utilization: Did existing commitments become stranded?
3
Coverage:Coverage: Did growth, expiration, or workload change create more On-Demand spend?
4
Discount mix and program cost: Did commitment type, pricing, or the cost to achieve savings change?
This separates ESR movement caused by legitimate workload changes from avoidable commitment waste.
How to improve ESR without adding waste
ESR improvement checklist
Recalculate ODE and net savings for the same services, accounts, and month.
Confirm which costs to achieve savings are included or excluded.
Use amortized costs consistently.
Review utilization and coverage by service or account.
Identify unused, mismatched, or expiring commitments.
Check planned migrations, decommissions, and resizing before adding coverage.
Model the value and downside of the next commitment layer.
The ESR triage matrix
| Current ESR | Investigate first | Primary action |
|---|---|---|
| Negative | Unused or mismatched commitments | Pause new purchases and diagnose stranded cost. |
| 0% to 14% | Utilization, then uncovered stable baseline | Reduce waste before expanding commitments. |
| 15% to 29% | Gap to the current 75th percentile | Add coverage selectively where usage is predictable. |
| 30% to 46% | Marginal savings versus risk | Model each additional ESR point before increasing exposure. |
| 47%+ | Durability | Focus on maintaining performance as workloads change. |
Choose the next commitment action
- Retain when utilization is strong and covered usage remains durable.
- Reduce future commitment volume when utilization is weakening or known workload reductions are approaching.
- Replace a poorly matched commitment only through provider-supported exchange, conversion, marketplace, return, expiry, or another applicable mechanism.
- Selectively add coverage when current commitments are healthy and additional On-Demand usage has a stable baseline.
What ESR does not tell you
ESR does not tell you whether workloads are efficient, whether commitments can be exited easily, or whether future usage will support today’s savings. It also cannot be compared fairly across teams that treat private pricing, credits, tooling costs, or labor differently.ProsperOps has presented ESR 2.0 at FinOps X as an expansion across broader clouds, services, and savings instruments. As of August 2026, the FinOps Foundation still publishes the established ESR formulas, so treat ESR 2.0 as an emerging extension rather than a directly comparable benchmark standard.
What comes after ESR: Insured Commitment Rate (ICR)
At Usage.ai, we introduced Insured Commitment Rate (ICR) to extend ESR by including cashback recovered from underutilized commitments. The idea is to measure a more risk-adjusted savings outcome, not just the savings achieved when commitments remain fully utilized.
ICR = (Cloud Savings + Cashback Recovered) / ODE Spend
Because cashback is added to cloud savings, ICR is greater than or equal to ESR. When commitments remain fully utilized, ICR and ESR are the same. When eligible underutilization triggers cashback, ICR reflects that recovered value in the overall savings rate.
This helps address one limitation of ESR: ESR can decline sharply, or even become negative, when commitment costs outweigh the savings generated. ICR adds the value recovered through cashback to show how that protection affects the final savings outcome.
For a deeper comparison with worked examples, read ESR vs ICR: The Savings Metric That Does Not Go Negative.
This helps address one limitation of ESR: ESR can decline sharply, or even become negative, when commitment costs outweigh the savings generated. ICR adds the value recovered through cashback to show how that protection affects the final savings outcome.
For a deeper comparison with worked examples, read ESR vs ICR: The Savings Metric That Does Not Go Negative.
Frequently asked questions
What is a good Effective Savings Rate?
Use a benchmark matching your scope. In the latest ProsperOps AWS compute cohort, the 2024 median was 15%, the 75th percentile 30%, and the 98th percentile 47%.
Can Effective Savings Rate be negative?
Yes. Negative ESR means the net commitment outcome was worse than the defined On-Demand baseline. The 2024 ProsperOps cohort included a minimum monthly AWS compute ESR of -29%.
Should tooling costs be included in ESR?
The FinOps Foundation formula allows the cost to achieve savings to be deducted from commitment savings. Define which platform, service, time, or tooling costs belong in scope and apply the policy consistently.
How often should FinOps teams calculate ESR?
Monthly is a practical reporting cadence. Monitor coverage and utilization more frequently so you can explain changes before the month closes.
Does ESR work for Azure and Google Cloud?
The ROI concept can be adapted across providers, but billing fields and discount instruments differ. Define ODE and actual-cost treatment separately for each provider.
Share
Facebook
X
LinkedIn
Reddit
