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."
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.
| Metric | What It Measures | Question It Answers | How It Can Mislead |
|---|---|---|---|
| Coverage | Share of eligible usage running on commitments | How much of our usage is committed? | High coverage says nothing about whether you use what you bought |
| Commitment utilization | Share of purchased commitments you actually used | Are we using what we bought? | Full utilization of a shallow discount still saves little |
| Discount rate | Price cut versus on-demand | How cheap is the committed rate? | A deep discount on a small slice of usage barely moves the bill |
| ESR | Net savings as a share of ODE spend | Did our commitments pay off? | One blended number can hide a weak area behind a strong one |
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.
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.
You need six numbers for one time window. The letters below match the FinOps Foundation playbook's worksheet.
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.
The numbers below are an illustrative example, not customer data. They show one month of commitment-eligible compute.
| Input | Label | Amount |
|---|---|---|
| Savings Plan ODE spend | A | $50,000 |
| RI ODE spend | B | $20,000 |
| Uncovered on-demand spend | C | $30,000 |
| Total ODE spend | D = A + B + C | $100,000 |
| Savings Plan savings | E | $15,000 |
| RI savings | F | $6,000 |
| Total savings | G = E + F | $21,000 |
| Cost to achieve | H | $1,000 |
| ESR | (G − H) / D | 20% |
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.
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.
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.
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:
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.
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.
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.
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.
If your providers export FOCUS data, you can run one calculation shape everywhere. Three FOCUS cost columns matter here:
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.
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.
ESR is a ratio. Change the top or the bottom and it moves, even when you did nothing to your commitments.
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.
| Metric | Before Rightsizing | After Rightsizing |
|---|---|---|
| ODE spend | $100,000 | $80,000 |
| Commitment savings | $21,000 | $14,000 |
| Cost to achieve | $1,000 | $1,000 |
| ESR | 20% | 16.25% |
| Actual bill | $80,000 | $67,000 |
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.
The math is simple. Keeping it comparable month after month is the hard part.
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.
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:
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.