Effective savings rate, or ESR, is the blended discount across your AWS compute spend. Take what the same usage would have cost at on demand rates, subtract what you actually paid, and divide by the on demand baseline. The result is one percentage that folds Savings Plans, Reserved Instances, Spot, and rate reductions like Graviton into a single buyer facing number. It is the cleanest way to answer the question a CIO actually asks: across everything we are doing, how much are we really saving, and is it going up or down.
This is an AWS commitments discipline, but the metric ranges wider than commitments alone. Here is how to calculate it, what a defensible figure looks like, and how to raise it without buying discount you cannot use.
What does effective savings rate actually measure?
ESR measures realised discount, not promised discount. A three year Savings Plan might advertise up to 66 percent off on demand for a specific instance family, but your estate never sits entirely under one rate. You run some usage on demand, some under Savings Plans, some on Reserved Instances, some on Spot, and some on Graviton instances that carry a lower base rate. ESR collapses all of that into one figure so you can compare quarter to quarter and team to team.
The formula is simple. For a period, sum the on demand equivalent cost of all eligible usage, then sum what you actually paid. ESR equals (on demand equivalent minus actual) divided by on demand equivalent. A bill that would have been one million dollars at list and came in at seven hundred thousand has a 30 percent effective savings rate.
How do you calculate it from the CUR?
The Cost and Usage Report, the CUR, is the source of truth. It carries the columns you need: the unblended cost you paid, the public on demand rate, and the usage amount, broken out by Savings Plan and Reserved Instance line items. To build ESR you reconstruct the on demand equivalent for every usage line, including the usage that a commitment covered, then compare it to actual spend.
Two practical cautions. First, decide your scope and hold it steady: most teams measure ESR on compute (EC2, Fargate, Lambda, and the database engines that take Reserved Instances) because that is where commitments apply, and mixing storage and data transfer in dilutes the signal. Second, treat Spot carefully. Spot savings are real but volatile, so many buyers report ESR both with and without Spot, because a number propped up by Spot can collapse when capacity tightens.
What is a good effective savings rate?
There is no universal target, because the ceiling depends on how much of your usage is steady enough to commit and how much is fault tolerant enough for Spot. As an indicative range, a mature estate with predictable compute often lands ESR between 25 and 40 percent once Savings Plan coverage, Spot for the right workloads, and Graviton migrations are all working together. Treat that band as indicative, not a goal to chase past the point your forecast supports.
The trap is optimising the headline number instead of the risk adjusted outcome. You can push ESR higher by buying more three year commitment, but if usage shifts and that commitment goes underused, your realised savings fall even as coverage looks high. The defensible target is the one your forecast can stand behind, which is why ESR is best read alongside sizing Savings Plan coverage without stranding spend.
ESR versus coverage versus utilization
Three numbers travel together and buyers conflate them at their cost.
- Coverage is the share of eligible usage that sits under a commitment. High coverage means little usage is exposed to on demand rates.
- Utilization is the share of your commitment that you actually consumed. Low utilization is money already spent on discount you did not use.
- Effective savings rate is the discount you realised after both effects. It is the outcome the other two produce.
You can have 90 percent coverage and a poor ESR if utilization slipped because usage moved off the committed instance families. Reading all three stops you from celebrating coverage while savings leak away.
How do you raise it safely?
A scaling fintech measured a 19 percent effective savings rate and assumed it was close to the ceiling. The CUR told a different story: Savings Plan coverage sat near 55 percent of steady compute, a third of the fleet was still on older instance families that Graviton could replace, and a batch tier that tolerated interruption ran entirely on demand. Laddering Savings Plan coverage up to the forecast floor, migrating the eligible fleet to Graviton, and moving the batch tier to Spot lifted ESR into the mid thirties. Figures are verified against billing data and anonymised.
The levers, in order of safety: migrate eligible workloads to Graviton and gp3, because those rate reductions do not expire and carry no commitment risk; raise Savings Plan coverage to your defensible forecast floor and ladder renewals so no single term cliffs at once; and route genuinely fault tolerant work to Spot. Each move is reflected in the next ESR reading, which is why the metric works as a feedback loop, not just a report. Manage the commitments behind it as a portfolio, covered in managing a Savings Plan portfolio.
Frequently asked questions
Raise your effective savings rate with us
We measure your effective savings rate from the CUR, separate real savings from busy coverage, and raise it with a risk adjusted plan your engineers will accept. It is the same discipline behind the 31 percent median reduction we see in the first 90 days. Our guarantee: we reduce your cloud spend or we reimburse our service fee.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.