Size Savings Plan coverage to the floor of your compute usage, not the average and never the peak. A Savings Plan commits you to a fixed dollar amount of compute per hour for one or three years in exchange for a discounted rate, up to 66 percent off on demand for Compute Savings Plans and up to 72 percent for EC2 Instance Savings Plans. Anything you commit above the level you reliably run every hour is stranded: you pay for it whether or not you use it. The defensible target covers the steady baseline, holds utilization near 100 percent, and leaves variable and uncertain demand on on demand or Spot.
Here is how to find that floor and ladder commitments around it.
How do Savings Plans actually charge you?
A Savings Plan is a commitment to spend a set dollar amount of compute per hour. Suppose you commit to 10 dollars per hour of Compute Savings Plan. Each hour, AWS applies the discounted rate to your eligible usage up to that 10 dollars of on demand equivalent, and anything beyond it bills at on demand. If in some hour you only run 7 dollars of eligible usage, the other 3 dollars of commitment is wasted for that hour. That waste is the strand, and it is permanent: there is no make good in a later hour.
This is why utilization, the share of your commitment you actually consume, matters as much as the headline discount. A 66 percent rate at 80 percent utilization can deliver a worse effective discount than a smaller commitment run at 99 percent.
How do you find the floor to commit to?
Pull at least 30 to 60 days of hourly eligible compute spend from the Cost and Usage Report. Eligible means EC2, Fargate, and Lambda for Compute Savings Plans. Plot the hourly run rate and find the level your usage stays at or above in almost every hour. That floor, not the average line, is your safe commitment base, because committing to the average guarantees you strand spend in every below average hour.
Then adjust for what you know about the future. If a workload is scheduled to migrate to Graviton, sunset, or move regions inside the term, discount it from the floor now rather than committing and regretting. The floor is a forecast, and the forecast is the product.
Compute versus EC2 Instance Savings Plans
The two plan types trade flexibility for rate.
| Dimension | Compute Savings Plan | EC2 Instance Savings Plan |
|---|---|---|
| Max discount | Up to 66 percent | Up to 72 percent |
| Flexibility | Any family, any region, EC2, Fargate, Lambda | Locked to one family in one region |
| Strand risk if you change architecture | Low | Higher |
| Best for | The mobile, evolving part of the floor | The stable, predictable core that will not move |
A common mix is to cover the deep, never moving core with EC2 Instance Savings Plans for the extra points, and cover the rest of the floor with Compute Savings Plans so a Graviton migration or region change does not strand you.
Why should you ladder terms instead of one big buy?
A scaling fintech committed its entire compute floor in one three year Savings Plan to chase the top rate. Six months later a major service moved to Graviton, the committed family fell out of use, and utilization dropped into the low 80s. The stranded commitment erased much of the discount the deeper rate was supposed to buy. We rebuilt the position as a ladder: roughly half on one year terms, the rest staggered across three year terms with quarterly start dates, sized to a conservative floor. Utilization returned to the high 90s and the effective savings rate rose even though the headline rate per plan was lower. Figures are verified against billing data and anonymised.
Laddering means buying commitment in tranches with staggered start dates and a mix of one and three year terms, rather than one large block that all expires together. It does three things: it keeps any single expiry from forcing a rushed renewal, it lets you re forecast every quarter, and it caps how much you can strand if one workload disappears. The slightly lower rate per tranche is cheap insurance against a stranded three year block.
What coverage and utilization should you target?
Aim to keep utilization near 100 percent, because every point below that is pure waste. Let coverage, the share of eligible spend under a commitment, settle wherever your defensible floor lands, which for a steady estate is often 70 to 85 percent of compute. Leave the variable top of demand on on demand and route genuinely fault tolerant work to Spot instances, where they fit and where they break. Read coverage, utilization, and effective savings rate together so you never celebrate coverage while savings leak away. The full commitment portfolio discipline sits in the AWS cost optimization guide, and the trade between commitment and elasticity is covered in Reserved Instances versus Savings Plans.
Frequently asked questions
Get the AWS Savings Plan sizing kit
We size Savings Plan coverage to a defensible forecast, ladder the terms, and keep utilization high so you capture the rate without carrying stranded commitment. It is the same discipline behind a scaling fintech we made 41 percent lighter, with zero provider commissions. 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.