- Blog
- Commitment Management
- Effective Savings Rate (ESR): The Metric That Actually Measures Cloud Commitment Performance
Effective Savings Rate (ESR): The Metric That Actually Measures Cloud Commitment Performance
Your cloud team walks into the quarterly review. “We hit 82% Reserved Instance coverage,” they announce. Everyone nods approvingly.
Three months later, the AWS bill is up 14%.
If that sounds familiar, you’re not alone. Many teams optimize for coverage or utilization metrics, only to find that actual savings don’t follow. The problem isn’t effort, it’s measuring the wrong thing.
Effective Savings Rate (ESR) changes that. It measures what matters: how much you’re saving versus on-demand prices. It distills down to a single outcome metric, i.e. the savings you actually realized.
In this guide, we’ll cover how to calculate your ESR, what our proprietary benchmark data says about real-world performance, and what separates world-class operators from everyone else (consistently hitting 35-50%+ ESR month after month).
What is the Effective Savings Rate (ESR)?
Effective Savings Rate (ESR) is a FinOps metric that shows your actual savings rate versus on-demand list pricing over a given period (typically monthly). The FinOps Foundation describes ESR as the “Return on Investment (ROI) for cloud discount instruments,” the output metric that reflects true savings performance.
ESR captures the real discount you’re receiving from commitments and rate levers (like Savings Plans, Reserved Instances, Committed Use Discounts, Azure Reservations, private rates, and Spot). That makes ESR the cleanest KPI to report to finance: one number that captures whether your commitment strategy is delivering.
How to Calculate Effective Savings Rate (ESR)
The FinOps Foundation calls ESR “the Return on Investment for cloud discount instruments”. If anything, that’s underselling it. ESR captures your actual cloud pricing efficiency in one number.
The core formula for calculating ESR is:
Breaking it down:
- Commitment Savings: The amount you saved on cloud cost by using cloud commitments, private rates, or Spot discounts.
- On-Demand Equivalent: The amount you would have paid (list price) without any discounts applied.
Or, another way of calculating the same is
Breaking it down:
- Amortized Cost: The effective cloud cost for the period after discounts, with any upfront commitment payments spread across their term to reflect the true cost of usage during that time.
- On-Demand Equivalent: The amount you would have paid (list price) without any discounts applied.
Real Numbers Example of ESR
Let’s look at a real-world example showing that ESR is a superior metric to track compared to coverage.
Effective Savings Rate on your Q4 2025 infrastructure:
- Actual amortized cost: $650,000 (What you paid)
- On-demand equivalent: $1,000,000 (What you would have paid)
- Savings: $350,000
- ESR: 35%
Coverage Rate for the same infrastructure during the same period
- RI coverage: 78% of usage subject to RI
- SP coverage: 15% of usage subject to RI
- On-Demand: only 7% of usage is not discounted
- Coverage Rate: 78% + 15% = 93%
Which tells the real story? That 93% suggesting near-perfect optimization? Or 35% showing your real savings rate??
Note: What Counts as Eligible
ESR focuses on commitment-eligible compute:
- AWS: EC2, Lambda, Fargate, SageMaker
- Azure: VMs, AKS, Batch
- GCP: Compute Engine, GKE
Storage (S3) doesn’t have commitments; they’re out.
Challenges with using utilization and coverage metrics instead of ESR
So why do coverage and utilization metrics often paint a misleading story? Because they measure inputs, not outcomes, and they break down under normal infrastructure change.
- 100% coverage with 50% utilization? Half your commitments burn cash for nothing. Coverage doesn’t measure this.
- Mismatch from normal infrastructure change. Instance drift (m5 → m6i), region moves, and architecture shifts (x86 → Graviton) can keep dashboards looking fine while savings drop.
- Demand volatility breaks both metrics. Spikes force on-demand spend (coverage drops when you need it most), and post-spike periods leave you overcommitted.
- Optimizing one often hurts the other. Conservative buying improves utilization but misses discounts; aggressive buying boosts coverage but increases stranded spend when usage declines.
Coverage vs. ESR Reality Check
Let’s take a quick look at how coverage, utilization, discount and ESR metrics compare under various common scenarios.
Scenario | Coverage | Utilization | Discount | ESR | What’s Really Happening |
“Optimized” | 85% | 70% | 40% | 24% | Wasting 76% of potential |
Selective | 60% | 95% | 45% | 26% | Better ESR, lower coverage |
Overcommitted | 95% | 55% | 42% | 22% | High coverage, poor returns |
Dynamic | 75% | 92% | 48% | 33% | Balance wins |
The pattern is clear: coverage doesn’t equal performance.
ESR Benchmarks: What Good Actually Looks Like
nOps manages thousands of cloud accounts across AWS, Azure and GCP.
We took a look at anonymized cloud data across across organizations pursuing a variety of optimization approaches.
The brual truth:
The Benchmark Reality
| Percentile | Rank | Effective Savings Rate |
|---|---|---|
| 98th percentile | World-Class | 51% ESR |
| 75th Percentile | Above average | 31% ESR |
| 50th percentile | Median | 18% ESR |
| 25th percentile | Below Average | 3% ESR |
Read that again. Half of all organizations achieve less than 18% ESR, while they could be effectively doubling or tripling their savings
What Separates Each Tier
Let’s take a look at some factors that characterize each rank:
35-50% ESR (Best-in-class)
- Rebalance commitments daily (or hourly)
- Mix RIs, Savings Plans, and Spot
- Automate drift detection
- Share commitments across accounts
- Review alignment constantly
18-30% ESR (Market average)
- Quarterly or monthly reviews
- Basic RI/SP but poor utilization
- Some automation
- Limited cross-account work
- React to big changes only
Below 15% ESR (Structural problems)
- Annual “set-and-forget” approach
- One commitment type only
- No utilization tracking
- Siloed accounts
- Overcommitted on old forecasts
Scale and industry factors are also relevant — big spenders averaging $10 million annually or more, SaaS companies, and cloud-native companies tend to perform slightly better on average ESR.
The Financial Impact of ESR at Scale
ESR is pure fuel for profit margin. Let’s model real impact across spending tiers to see how quickly it compounds.
$5M Annual Compute:
- Current: 20% ESR (saving $1M)
- Target: 35% ESR (saving $1.75M)
- Gain: $750K annually
- 3-year value: $2.25M
$25M Annual Compute:
- 5% ESR boost = $1.25M/year
- 10% boost = $2.5M/year
- 15% boost = $3.75M/year
- 3-year value at 15%: $11.25M
$100M Annual Compute:
- Each 1% ESR = $1M/year
- 20% → 35% ESR = $15M/year
- 3-year value: $45M
ESR Belongs in Board Decks
Take a company with $100M in revenue and $10M in annual cloud spend.
If we improve effective savings rate (ESR) from 20% to 35%, that’s an incremental $1.5M in EBITDA.
That translates to a 1.5% operating margin improvement.
At a 20x EBITDA multiple, that $1.5M improvement drives approximately $30M in additional enterprise value.
This is board-level financial impact.
The Hidden Cost of Low ESR
Conversely, low ESR can be a huge drag on profits. Beyond direct losses:
- Cash trap: Overcommitments lock up growth capital
- Agility killer: Wrong commitments block flexibility
- Tech debt signal: Mismatched commitments reveal architectural drift
- Team drain: Manual management eats 10-20 hours monthly
Six Causes of Low ESR
If your Effective Savings Rate is lower than expected, it’s typically the result of structural patterns in how commitments are bought, managed, and adjusted over time.
Below are the most common causes of low ESR we’ve seen in customer environments before optimization.
- Infrequent commitment buying. When commitments are purchased infrequently (e.g. once a month) based on a snapshot of usage, they gradually fall out of sync with reality. Workloads evolve, traffic patterns change, and new services are adopted, but the portfolio remains static. As that gap widens, more usage runs on-demand or older commitments become underutilized, lowering realized savings.
- Account-level isolation. When commitments are managed independently by account, imbalance is common. One account may have excess commitments while another pays on-demand for similar usage. Without centralized oversight and sharing, the organization absorbs that inefficiency.
- Instance family drift. Engineering teams upgrade instance families and architectures regularly. If the commitment portfolio doesn’t adjust at the same pace, older-family commitments sit idle while newer-family usage runs on-demand. The result isn’t obvious in coverage dashboards, but it shows up in reduced effective savings.
- Container and serverless growth. Many strategies focus heavily on EC2, even as compute shifts into Fargate and Lambda. As those services grow, a larger share of eligible spend falls outside the commitment strategy, which lowers overall realized savings.
- Database spend outside the strategy. Databases can be a larger portion of total spend, and can cost you big if they’re included in the commitment and discount strategy. Fortunately, Database Savings Plans are now available.
How Leading Teams Achieve 35-50%+ ESR
Hitting a high ESR consistently comes down to process. Below are the practices leading teams use to keep commitments aligned as usage changes.
1. Dynamic Laddering
To get maximum benefit, you have to manage commitments hourly, because usage changes continuously. The goal is to catch drift as it starts—before it turns into weeks of underutilization or on-demand exposure—and then make small adjustments on a steady cadence rather than large risky bets.
Smaller, incremental commitments reduce timing risk, allow gradual scaling up and down, and make realignment manageable.
Here’s a simple example of where a company with $10M in annual compute spend might land in terms of commitment mix, each split over hundreds or thousands of individual commitments.
- 30% in 3-year Compute SPs (foundation)
- 40% in 1-year mixed (flexibility)
- 20% quarterly-adjusted (agility)
- 10% on-demand (spike buffer)
2. Portfolio Approach
Like investing, diversify commitments:
Type | Allocation | Use Case | ESR Impact |
3-year Compute SP | 25-35% | Stable base | Up to 66% discount |
1-year EC2 SP | 20-30% | Predictable families | 40-50% discount |
Convertible RIs | 15-25% | Some flexibility needed | 35-45% discount |
Spot | 10-20% | Fault-tolerant work | Up to 90% discount |
On-Demand | 10-15% | Pure flexibility | 0% but agile |
3. Automate Everything
At scale, managing commitments manually is not realistic. Usage shifts hourly across services, accounts, instance families, regions, and architectures. A single change—an autoscaling adjustment, a deployment, a regional failover—can alter commitment alignment immediately. Tracking that manually across hundreds of commitments and thousands of resources simply doesn’t scale.
Sustaining a high ESR requires continuous portfolio management: detecting drift as it happens, evaluating its financial impact, and adjusting exposure in small increments before inefficiencies compound. That means orchestrating purchases, expirations, sharing rules, and risk thresholds across the entire organization
4. Manage at the Organization Level
Account silos reduce ESR because commitments and usage don’t stay neatly contained in the same place, so high-performing teams manage commitments at the org level:
- Central purchasing via the billing (payer) account to control the portfolio holistically
- Auto-sharing across the organization so discounted capacity flows to where usage actually happens
- Aggregated demand analysis to spot portfolio-level opportunities (flexibility vs. depth, where to commit more/less)
- Chargeback that doesn’t punish sharing so teams aren’t incentivized to hoard or avoid discounted capacity
5. Workload-First Thinking
Commitments work best when the environment is designed to stay compatible with them. Teams with strong ESR reduce avoidable churn and keep workloads “commitment-friendly” by:
- Standardizing instance families and configurations so usage stays eligible for the same commitments over time
- Consolidating regions where it’s practical to avoid commitments getting stranded after regional shifts
- Using scheduling and predictable run windows to increase the percentage of usage that lands on discounted capacity
- Making architecture choices with pricing in mind (e.g., where flexibility is needed vs. where steady-state can be committed)
Calculate & Benchmark Your Effective Savings Rate in 5 Minutes
Skip the complex tools. Here’s ESR calculation using AWS Cost Explorer.
Step 1: Get On-Demand Equivalent (ODE)
aws ce get-cost-and-usage \ --time-period Start=2026-01-01,End=2026-02-01 \ --metrics "OnDemandCostEquivalent" \ --granularity MONTHLY \ --filter file://compute-filter.json (compute-filter.json includes EC2, Lambda, Fargate, SageMaker) Step 2: Get Amortized Cost
aws ce get-cost-and-usage \ --time-period Start=2026-01-01,End=2026-02-01 \ --metrics "AmortizedCost" \ --granularity MONTHLY \ --filter file://compute-filter.json Step 3: Calculate
ESR = 1 – (Amortized Cost / On-Demand Equivalent)
Real example:
- ODE: $487,290
- Amortized: $341,103
- Savings: $146,187
- ESR: 30%
Step 4: Quick Assessment
| Your ESR | Meaning | Next Steps |
|---|---|---|
| <15% | Severe Issues | Emergency Review |
| 15-25% | Below Average | Find Biggest Gaps |
| 25-35% | Competitive | Keep Improving |
| 35-45% | Above Average | Fine-Tune |
| >45% | Best In Class | Share Secrets! |
Advanced Analysis of your ESR
Want to go a little more involved than a single ESR number? Segment ESR so you can see exactly where savings performance is strong (or weak):
Service: EC2 vs. Lambda vs. Fargate — which services are driving (or dragging) your realized savings?
Account: which teams/accounts consistently optimize well, and which need attention?
Region: where are you overcommitted or underutilized based on regional usage patterns?
Instance family: which families drift most over time, creating mismatch and waste?
Time: how is ESR trending month-over-month, and what changed when it moved?
And rather than piecing this together yourself, why not have nOps do it for you? We can run a free ESR analysis to benchmark where you are today, pinpoint the biggest drivers of variance across those segments, and quantify the realistic improvement range—so you walk away with clear, prioritized next steps.
Maximize your ESR with nOps
The data’s stark — many organizations hit 0% ESR despite extensive commitments. But leaders achieving 35-50% prove dramatic gains are possible.
This is where nOps comes in, as a purpose-built automation platform designed to maximize your ESR on autopilot, freeing your engineering team to focus on building and innovating.
Adaptive commitment laddering: maximize ESR without lock-in
nOps continuously adjusts commitments in small increments based on real demand, helping teams achieve optimal savings rates without risk or manual overhead.
Savings-first pricing
nOps only gets paid after it saves you money. There’s no upfront cost, no long-term commitment, and no risk or downside — if nOps doesn’t deliver measurable savings, you don’t pay.
Want to see it in practice? Book a demo to get a free savings analysis of your AWS/Azure/GCP spend.
nOps manages $3B+ in cloud spend and was recently rated #1 in G2’s Cloud Cost Management category.
Last Updated: February 25, 2026, Commitment Management
Last Updated: February 25, 2026, Commitment Management