Effective Savings Rate (ESR): Measure Commitment Savings

Key Takeaways

• What ESR is: Effective savings rate (ESR) is the share of on-demand equivalent spend your commitment discounts saved, net of the costs to get them.
• Why coverage and utilization aren't enough: Both can look healthy while the bill barely moves, because neither one measures how much money your commitments returned.
• The baseline decision: The FinOps Foundation divides by on-demand equivalent spend, FOCUS divides by contracted cost, and you need to pick one and keep it.
• Where to start: Measure commitment savings over a full month, for the same accounts and services each time, using one baseline.

What Is Effective Savings Rate (ESR)?

Effective savings rate (ESR) is the percentage you saved on commitment-eligible usage compared with what that usage would have cost at on-demand rates. On-demand rates are the standard pay-as-you-go prices, with no discount applied.

Commitment discounts trade a promise to spend or use a set amount for a lower rate. They include Savings Plans and Reserved Instances (RIs) on AWS, reservations on Azure, and committed use discounts (CUDs) on Google Cloud.

The FinOps Foundation ESR playbook shows the basic math: "Example: $5,000 in SP Savings / $10,000 in ODE Spend = 50% Effective Savings Rate." SP means Savings Plans, and ODE means On-Demand Equivalent spend. The playbook defines ODE spend as "the cost that would have been incurred without any discounts."

Put simply, ODE spend is the bill you'd get if every commitment vanished overnight. ESR tells you how much smaller your real bill was.

Why does that matter? Finance doesn't ask how much usage you covered. Finance asks whether the commitments paid off, and the FinOps Foundation playbook frames ESR as "the Return on Investment (ROI) for cloud discount instruments."

How Does ESR Compare to Coverage, Utilization, and Discount Rate?

ESR is an output: what you saved. Coverage, utilization, and discount rate are inputs: how your commitments are set up and used.

The FinOps terminology definitions describe coverage as "The percentage of eligible workloads that were covered by active commitments during the specified period." They define commitment utilization as "The percentage of active commitments utilized during the specified period." Discount rate is how far below the on-demand price your committed rate sits.

The FinOps Foundation playbook also shows how the inputs combine: "90% SP Utilization x 100% Coverage x 50% Discount = 45% Effective Savings Rate." Any weak term caps the result. High coverage with low utilization caps ESR, and high utilization with a shallow discount caps it too.

That's the "healthy dashboards, flat bill" problem. If you already track coverage and utilization KPIs, ESR is the number that sits on top of them.

How to Calculate ESR

ESR divides your net commitment savings by your ODE spend. The FinOps Foundation playbook writes it as "(RI & SP Savings minus Costs to Achieve Savings Outcome) / On-Demand Equivalent Spend."

Cost to achieve is what you spend to get the savings, such as tooling, services, and team time. The term is optional, but you need to say whether you include it.

The Inputs You Need

You need six numbers for one time window. The letters below match the FinOps Foundation playbook's worksheet.

• Savings Plan ODE spend (A): What your Savings Plan-covered usage would have cost at on-demand rates.
• RI ODE spend (B): What your RI-covered usage would have cost at on-demand rates.
• Uncovered on-demand spend (C): Eligible usage that no commitment covered, billed at on-demand rates.
• Total ODE spend (D): The sum of A, B, and C, which becomes your denominator.
• Savings Plan savings (E) and RI savings (F): The dollars each instrument saved against on-demand, added together as G.
• Cost to achieve (H): Optional spend on tooling, services, or team time needed to get the savings.

Your instrument choice changes how deep the discount runs and how much flexibility you keep. If you're weighing Savings Plans versus Reserved Instances, that tradeoff shows up directly in E and F.

A Worked Example

The numbers below are an illustrative example, not customer data. They show one month of commitment-eligible compute.

ESR = ($21,000 − $1,000) / $100,000 = 20%.

Notice that the $30,000 of uncovered usage stays in the denominator. It earns no discount, and it pulls ESR down exactly as it should.

Choose Your Baseline Before You Calculate

A baseline is the "full price" you compare against. Two published ESR formulas use different ones.

The FinOps Foundation playbook divides by ODE spend, which starts from on-demand prices. The FOCUS ESR use case uses a different denominator: "The KPI calculation is (Contracted Cost – Effective Cost) / Contracted Cost."

FOCUS is the FinOps Open Cost and Usage Specification, a common format for billing data. Contracted cost is your price after negotiated discounts, such as an enterprise agreement rate. That means the FOCUS version leaves negotiated savings out and measures commitment savings alone.

Neither formula is wrong. They answer different questions, and the same month can produce two different ESRs.

Pick one, write it down, and keep it constant. If you run more than one cloud, use that baseline on all of them. A list-price ESR and a contracted-cost ESR can't be blended.

How to Pull ESR Inputs From AWS, Azure, and Google Cloud

Each provider labels the same ideas differently. The FinOps Foundation playbook recommends a full month as the time window, and using one window everywhere keeps your clouds comparable.

AWS

The FinOps Foundation playbook walks through AWS compute, covering EC2, Fargate, and Lambda. It notes that ODE spend "is not available from some common reporting tools, such as AWS Cost Explorer Console." The Cost Explorer CLI returns it.

The playbook uses three CLI calls to collect the inputs:

• get-savings-plans-utilization: Returns OnDemandCostEquivalent and NetSavings for your Savings Plans.
• get-reservation-utilization: Returns OnDemandCostOfRIHoursUsed and NetRISavings for your RIs.
• get-savings-plans-coverage: Returns OnDemandCost, which the playbook uses for usage that ran at on-demand rates.

Pull all three for the same full month. A utilization pull and a coverage pull from different windows give you a denominator that doesn't match the numerator.

Azure

Microsoft documents reservation savings for Enterprise Agreement (EA) and Microsoft Customer Agreement (MCA) accounts. The method uses the Amortized Cost dataset, which spreads each reservation's price across the usage it covers and lists unused hours.

1. Multiply UnitPrice by Quantity to estimate pay-as-you-go cost, as if no reservation applied.
2. Sum the Cost values to get what you paid for the reservation, including used and unused portions.
3. Subtract the second number from the first.

The Azure reservation savings steps state the last step plainly: "Subtract reservation costs from estimated pay-as-you-go costs to get the estimated savings." Microsoft adds that "Any UnusedReservation quantity reduces savings."

Watch the baseline here. UnitPrice comes from your price sheet, which may already include negotiated pricing. If it does, your Azure savings sit on a contracted-cost baseline, not a list-price one.

Google Cloud

The Google Cloud cost breakdown report notes: "For costs incurred after May 1, 2021, your on-demand rate is based on the publicly available list prices." The report starts from gross cost at that on-demand rate and shows negotiated savings on their own line, apart from CUD savings.

That layout lets you choose a list-price or contracted baseline on purpose. Google's page doesn't define ESR, though. You build it from these parts.

Fee handling is the trap. For legacy spend-based CUDs and resource-based CUDs, the purchase fee sits inside usage cost.

For the newer spend-based CUDs, the fee is netted into the CUD savings amount instead. Subtract each fee once.

Across Clouds With FOCUS

If your providers export FOCUS data, you can run one calculation shape everywhere. Three FOCUS cost columns matter here:

• ListCost: The pre-discount baseline, before negotiated or commitment discounts.
• ContractedCost: Your price after negotiated discounts.
• EffectiveCost: The amortized view, which spreads commitment purchases across the usage they cover.

The FOCUS cost comparison guidance states that "comparing ContractedCost against EffectiveCost isolates commitment discount savings." Treat the FOCUS use-case query as a starting point, and filter charge categories and classes the way the specification's comparison example does. Check how each provider fills these columns before you trust a cross-cloud total.

What Is a Good ESR?

There's no universal number. A good ESR depends on your instrument mix, term length, service mix, and how steady your usage is.

A better test is your own ceiling. Start with the average discount you bought, which is the most ESR could reach with full coverage and full utilization.

Then multiply in your actual coverage and utilization for the same accounts and services. If the result matches your measured ESR, those two inputs explain the gap. If measured ESR is lower, something else is leaking, such as fees, cost to achieve, or a baseline mismatch.

After that, watch the trend. A rising ESR on the same accounts, services, and baseline tells you more than any outside number.

Why Your ESR Moves From Month to Month

ESR is a ratio. Change the top or the bottom and it moves, even when you did nothing to your commitments.

• ODE changes: Usage grows or shrinks, which changes the denominator.
• Utilization changes: Workloads shift off the instances you committed to, leaving paid-for commitment unused.
• Coverage changes: New usage lands outside your commitments, or existing commitments expire.
• Discount mix changes: A shift between RIs and Savings Plans, or between terms, changes your average discount.

Commitments sized for last year's workloads drift as those workloads change. It helps to understand why commitments go stale before your next purchase.

Rightsizing can lower ESR while it lowers the bill. Rightsizing means moving workloads to smaller or cheaper resources that still meet demand. Here's the same illustrative example after a rightsizing push.

Savings fall because some commitment now goes unused, and ESR drops to ($14,000 − $1,000) / $80,000. The bill still drops by $13,000.

ESR measures how efficiently you buy. Read it next to total cost, never alone.

One blended ESR can also hide a weak area behind a strong one. Segment it by service, account, and owner, and a team that moved off a committed instance family shows up long before the total moves.

Common ESR Pitfalls and How to Avoid Them

The math is simple. Keeping it comparable month after month is the hard part.

• Mixing baselines: A list-price ESR from one cloud and a contracted-cost ESR from another can't be added. Use one baseline everywhere.
• Leaving out cost to achieve: A gross ESR looks better than a net one. Label your version and keep it the same each month.
• Reporting only the total: When the number drops, finance has nobody to ask. Report ESR by owner next to the total.
• Chasing ESR with rigid long commitments: Longer terms and narrower instruments raise the discount. They also raise the cost of being wrong later.
• Counting Spot or negotiated discounts: Spot pricing for spare capacity and negotiated rates aren't commitment savings. Keep them out of the numerator.
• Reading a one-day ESR as a trend: The FinOps Foundation playbook notes, "Your ESR is measured at a point in time and can fluctuate daily."

Lock-in deserves extra care right now. With shrinking Reserved Instance flexibility, including an Azure exchange-rights change for reservations bought from February 1, 2027, a wrong commitment costs more to unwind.

What Does This Mean in Practice?

Use ESR to decide what to do next with your commitments. Start from the situation you're in.

If your ESR is negative, fix that first, because you're paying more than on-demand for committed usage. The FinOps Foundation playbook describes it this way: "You pay a premium over the on-demand rate for compute, likely due to overcommitment and/or underutilized commitments." The playbook suggests "letting them expire or adjusting them to match your usage."

If utilization is low, prioritize it over new purchases, because unused commitment is pure cost. Check whether workloads moved to other instance families, regions, or services.

If coverage is low on steady usage, that's where new commitments earn their keep, because steady usage keeps utilization high. Commit to the usage floor you're confident in, and leave the peaks on-demand.

If rightsizing or a migration is about to shrink usage, finish it before you commit, because commitments sized to today's waste lock that waste in. Fix usage first, then lock in rates.

If you run AI commitments, keep them out of your cloud ESR unless they work the same way. Compare cloud and AI commitment models first, because blending different contract shapes makes the ratio harder to read.

Each role reads ESR a little differently:

• FinOps: Own the baseline, the time window, and the segment definitions, and keep all three stable.
• Engineering: Flag rightsizing and migrations early, because both change ODE spend and utilization.
• Finance: Read ESR next to total cost, and ask which baseline and version the number uses.

How Finout Helps You Measure Commitment Savings

Finout is an enterprise-grade FinOps platform for cloud and AI spend, built for the agentic era. Finout shows the inputs ESR is built from and ties them to the owners who can act on them.

My Commitments covers AWS and Azure. On AWS, the Executive Summary shows Coverage, Reserved Instances Utilization, Saving Plans Utilization, Total Savings, Total Underutilized Waste, and Discount Rate.

The My Commitments documentation notes: "AWS presents savings per plan coverage at a yearly level, whereas Finout provides these calculations at a daily level." The metrics reflect the latest daily snapshot from the AWS API.

The RI Explorer in My Commitments shows the hourly On-Demand Baseline per purchase group, by instance family, region, and operating system. An Upcoming Commitments Expirations table shows what's about to roll off.

You can filter these views by Virtual Tags to see commitment metrics for each tag value. You can also filter by dimensions from the MegaBill, Finout's unified cost and usage layer.

On Azure, My Commitments shows less. For Azure Reservations, Finout shows coverage and utilization, not dollar savings, waste, or discount rate, because Azure doesn't expose a monetary commitment value for Reservations.

CostGuard Scans runs Commitment scans for EC2 Savings Plans, EC2 Reserved Instances, and Compute Savings Plans. These scans identify consistently running resources that fit one- or three-year terms.

CostGuard unifies those findings with recommendations from native cloud tools, third-party tools, and custom logic. Policy-driven thresholds cut the noise, leaving the commitment work that matters.

FinOps Dashboards send commitment views as reports through Slack, email, or Teams. Each report can go to a specific team based on its Virtual Tags value.

Want to see your commitment inputs by owner? Book a demo.