Your RI coverage is 85% and your AWS bill is still climbing. ESR explains why coverage metrics lie to you, how to calculate the number that actually tells the truth, and what to do once you have it.
What Is Effective Savings Rate (ESR)?
Effective Savings Rate (ESR) is a FinOps KPI that measures the true ROI of cloud discount instruments. Introduced by ProsperOps co-founder Erik Carlin in 2019, it's now a FinOps Foundation standard under the Rate Optimization capability and AWS embedded it natively in 6the Cost and Usage Dashboard's Summary Billing tab.
Before ESR, FinOps teams tracked two proxy metrics:
- Coverage: what percentage of your resources have a discount applied? Says nothing about whether it's actually saving you money.
- Utilization: what percentage of purchased commitments are being consumed? Says nothing about whether you bought the right amount or type.
ESR answers the real question: what is the net percentage discount you're receiving across your entire eligible cloud spend, after accounting for coverage, utilization, and discount rate simultaneously?
The Formula
There are two equivalent forms:
Form 1 (Division):
ESR = 1 – (Actual Spend / On-Demand Equivalent Spend)
Form 2 (Savings):
ESR = Cloud Savings Generated / On-Demand Equivalent Spend
What each term means:
- On-Demand Equivalent (ODE) Spend: the theoretical cost of running your exact workloads at full on-demand pricing with zero discounts. Your denominator. It only changes when actual resource usage changes.
- Actual Spend Including Discounts: what you actually paid after all discount instruments are applied, including amortized upfront RI costs.
- Cloud Savings Generated: ODE minus Actual Spend.
A $1M ODE with $700K actual spend = $300K savings = 30% ESR.
ESR is multiplicative. Improving coverage, utilization, or discount rate all move it but they interact. 90% coverage with 70% utilization and a 30% discount rate will underperform 70% coverage with 95% utilization and a 40% discount rate. ESR captures the net outcome of all three.
How to Calculate ESR from AWS CUR
The AWS Cost and Usage Report (CUR) is the right data source. Native dashboards give approximations; CUR gives you the exact number.
Prerequisites:
- CUR enabled with resource-level granularity
- Report includes amortized costs
- Filtered to commitment-eligible services: EC2, Fargate, Lambda, RDS, ElastiCache, Redshift, OpenSearch
Step 1: Sum lineItem/NetAmortizedCost for your target services → Actual Spend
Step 2: Sum pricing/publicOnDemandCost for the same line items → ODE Spend
Step 3: ESR = 1 – (Net Amortized Cost / Public On-Demand Cost)
/* Run against your CUR Athena table */
SELECT
bill_billing_period_start_date AS billing_period,
SUM(line_item_net_amortized_cost) AS actual_spend,
SUM(pricing_public_on_demand_cost) AS ode_spend,
ROUND(
(1 – SUM(line_item_net_amortized_cost) /
NULLIF(SUM(pricing_public_on_demand_cost), 0))
* 100, 2
) AS esr_percent
FROM your_cur_table
WHERE
line_item_product_code IN (
'AmazonEC2', 'AmazonRDS', 'AmazonElastiCache',
'AmazonRedshift', 'AWSLambda'
)
AND pricing_public_on_demand_cost > 0
GROUP BY 1
ORDER BY 1 DESC;
Common errors to avoid:
- Using blended cost instead of net amortized cost blended averages rates across an org and doesn't reflect actual commitment discounts
- Including data transfer, support, or marketplace charges, they have no commitment-eligible on-demand equivalent and will deflate your ESR
- Forgetting upfront RI costs lineItem/NetAmortizedCost handles amortization automatically; unblended cost does not
- Calculating over a single day billing timing causes daily ESR to swing wildly; always use a full calendar month
ESR for Azure and GCP
The formula is identical across all three clouds. The data sources differ.
Azure:
- Actual Spend: CostInBillingCurrency from usage detail export
- ODE Spend: PayGPrice × Quantity from the same export
- Commitment types: Azure Reservations, Azure Savings Plans
- Native ESR view: Cost Management Rate Optimization view (verify at portal.azure.com)
GCP:
- Actual Spend: cost field in Cloud Billing BigQuery export
- ODE Spend: on_demand_cost from the same export
- Commitment types: Committed Use Discounts (CUDs)
- Native ESR view: None as of Q1 2025 must calculate from BigQuery
Azure and GCP field names change periodically. Verify against official documentation before building any calculation pipeline.
Industry Benchmarks: What Good Actually Looks Like
ProsperOps published a 2024 benchmarking report analyzing $1.5B+ in annualized AWS compute spend across hundreds of organizations all sourced from prospect accounts before adopting any optimization tool.
- 0% Median ESR. Half of all organizations save nothing on compute.
- 23% 75th percentile. Above average for active FinOps teams.
- 46% 98th percentile. World-class. Requires sophisticated automation.
- -9% Minimum observed. Overcommitment costs more than on-demand.
The 0% median is the most important number. At $500K/year in compute spend, moving from 0% to 25% ESR saves $125K annually without touching architecture or rightsizing.
Dollar impact of ESR improvement: Annual Savings = Annual Compute ODE Spend × ESR Improvement. A 5 percentage point improvement on $10M/year = $500K saved annually.
Why High Coverage Does Not Mean High ESR
This is the most common misconception in cloud cost optimization. Teams hit 85% RI coverage, present it in a quarterly review, and then find their bill went up anyway.
Compare two environments, both at $1M/month ODE spend:
- Environment A: 75% coverage, 100% utilization, 30% discount → $225K saved → 22.5% ESR
- Environment B: 100% coverage, 55% utilization, 30% discount → $165K saved → 16.5% ESR
Environment B has higher coverage. Environment A has higher ESR. The difference is utilization: Environment B bought 100% coverage but only consumed 55% of it. The stranded 45% is still charged, reducing net savings.
Coverage is a process metric. ESR is an outcome metric.
Six Reasons Your ESR Is Low
No commitments at all: 53% of AWS organizations use zero Savings Plans or Reserved Instances. ESR is 0% by definition.
Low coverage on high-spend resources: Commitments applied to smaller workloads while the largest, most expensive resources run on-demand.
Overcommitment and low utilization: Utilization below 70–80% means stranded commitment hours are pulling ESR toward negative.
Wrong instance family or region: Standard RIs are instance-family-specific. Buying m5 RIs when workloads migrated to m6i means zero coverage but full charges.
Suboptimal commitment type: Choosing 1-year No Upfront when 3-year Partial Upfront delivers 20+ percentage points higher discount. Coverage exists; savings don't.
Stale recommendations: AWS Cost Explorer refreshes every 72+ hours. Usage shifts within that window create coverage gaps invisible to the recommendation engine until the next refresh.
How to Improve ESR
If coverage is below 60%: Sort your CUR by pricing/publicOnDemandCost descending. The top 20% of resources typically represent 60–70% of total ODE. Start with Compute Savings Plans they apply across EC2, Fargate, and Lambda regardless of region, family, or OS, with 66% of the maximum available discount and maximum flexibility.
If utilization is below 80%: Let commitments expire without renewal, exchange Convertible RIs for instance types you're actually running, or sell Standard RIs in the AWS RI Marketplace. For Savings Plans, there's no exchange either to absorb the waste until expiry or recover value through a cashback platform.
If discount rate is below 25%: AWS EC2 Compute Savings Plans deliver ~40% savings on 1-year No Upfront and up to 66% on 3-year All Upfront. Moving from 1-year No Upfront to 3-year Partial Upfront on stable workloads can add 15–25 percentage points to effective discount rate directly.
If recommendations refresh slowly: For dynamic workloads, the 72+ hour AWS Cost Explorer lag is a measurable, recurring ESR drag. Faster data loops mean coverage adjustments happen closer to when usage actually changes.
Tracking cadence: ESR is a lagging indicator, measured monthly, not daily. Track at three levels: total ESR, ESR by service group (EC2/Fargate separate from RDS), and ESR by account in a multi-account org. An average of 28% across 10 accounts can hide one account at -5% dragging down nine accounts averaging 32%.
Usage.ai customers across 300+ enterprises have closed this gap. Motive reduced annual cloud spend by $5.2M. EVGo (NASDAQ: EVGO) saved $2.3M annually. Secureframe saved $480K and reinvested it directly into product growth.
What ESR Cannot Measure
Commitment risk: ESR shows savings performance, not whether those savings are protected if usage drops. The -9% minimum in the benchmark data came from real organizations that committed aggressively and then saw usage fall. ESR recorded what happened. It couldn't be prevented.
Cashback vs. credits: Some platforms compensate for underutilized commitments with real-money cashback spendable anywhere; others with vendor-locked credits redeemable only against future spend on the same cloud. ESR treats both identically.
Exit cost exposure: ESR measures ongoing savings rate while a tool runs. It doesn't measure financial obligations triggered by stopping. Some platforms include contractual terms that trigger fee obligations on unrealized future savings if a customer exits before commitment terms expire. Completely invisible in ESR.
What Comes After ESR: Insured Commitment Rate (ICR)
Insured Commitment Rate (ICR), introduced by Usage.ai, extends ESR by adding cashback recovered on underutilized commitments to the numerator:
ICR = (Cloud Savings + Cashback Recovered) / ODE Spend
ICR is always ≥ ESR because cashback is additive. When every commitment is fully utilized, ICR equals ESR. When utilization drops and cashback kicks in, ICR exceeds ESR by exactly the value recovered.
ESR can go negative. ICR cannot every underutilized commitment is offset by real-money cashback rather than absorbed as a loss.
For the full comparison with worked examples ESR vs ICR: The Savings Metric That Does Not Go Negative
Start with ESR. Know your number. Then ask whether the savings you've built are as durable as they look on paper.
What's your current ESR, and which of the six root causes have you run into most often?
Explore the full operational breakdown here → Effective Savings Rate (ESR): The Complete FinOps Guide to Calculating and Improving Your Cloud Savings ROI
Top comments (0)