A sound AWS commitment renewal follows a fixed sequence: review utilisation and coverage on the expiring term, rebuild the forward forecast from current usage rather than last year's, decide the split between Savings Plans and Reserved Instances, size coverage to the baseline you are confident in, and stage the purchase so you are never overcommitted on the day the old term lapses. Done this way, renewal protects savings without locking you into capacity you will not use.
The expensive mistake at renewal is to roll the expiring commitment forward at the same size out of habit. Usage has moved, instance families have changed, and the workload you committed to three years ago may not be the workload you run now. Treat every renewal as a fresh sizing exercise.
What do I review before an AWS commitment renews?
Start with the record the expiring term leaves behind. Pull utilisation and coverage for the full term from the Cost and Usage Report and the Savings Plans and Reserved Instance utilisation reports. Three numbers matter: the utilisation rate, which tells you whether you used what you bought, the coverage rate, which tells you how much of eligible usage the commitment carried, and the effective savings rate, which tells you what the commitment actually returned against on demand.
If utilisation ran below the high nineties, you overbought last time and should size down. If coverage ran low while utilisation was full, you have room to commit more. We unpack that second number in measuring effective savings rate on AWS.
How do I build the forecast the renewal sizes to?
Coverage follows a defensible forecast, never a hopeful one. Rebuild the forward baseline from the last few months of steady state usage, strip out anything already scheduled for migration or shutdown, and separate the stable baseline from the variable top layer. The baseline is what you commit to. The variable layer stays on demand or on Spot, because committing to it is where stranded spend comes from.
Factor in known moves. A planned Graviton migration changes which instance families you will run. A rearchitecting effort that shifts load to managed services lowers the EC2 baseline. A renewal sized to today's bill ignores tomorrow's plan and strands spend the moment the migration completes.
Savings Plans or Reserved Instances at renewal?
The choice is flexibility against specificity. Compute Savings Plans apply across instance family, size, region, and even between EC2, Fargate, and Lambda, so they absorb change. Reserved Instances and EC2 Instance Savings Plans tie to a narrower scope in exchange for a slightly deeper discount. The risk adjusted answer is usually to cover the stable, predictable core with the deeper discount instrument and the moving layer with Compute Savings Plans, so flexibility sits exactly where change is most likely.
A scaling fintech approached a three year renewal planning to roll its expiring Reserved Instances forward unchanged. Rebuilding the forecast showed a Graviton migration would retire a third of the committed families within two quarters. Splitting the renewal into a smaller Reserved Instance core plus Compute Savings Plans for the rest covered the real baseline and avoided stranding spend on families about to disappear. The wider engagement left the estate 41 percent lighter. Figures are verified against billing data and anonymised.
One year or three year term?
Term length is a bet on forecast confidence. A three year commitment buys the deepest discount but assumes the workload still exists and still looks similar in three years. A one year commitment costs more per unit but keeps you flexible. Match term to certainty: three year on the stable core you would run regardless, one year on anything you expect to evolve, and on demand on the genuinely uncertain.
The renewal checklist
| Step | Question to answer |
|---|---|
| 1. Review | What were utilisation, coverage, and effective savings rate on the expiring term? |
| 2. Forecast | What is the defensible forward baseline once migrations and shutdowns are removed? |
| 3. Instrument | Which spend is stable enough for Reserved Instances, and which needs Savings Plan flexibility? |
| 4. Size | What coverage level keeps utilisation in the high nineties on the baseline? |
| 5. Term | Where does three year confidence end and one year flexibility begin? |
| 6. Stage | How do you ladder purchases so no single expiry forces a rushed renewal? |
Laddering matters most. Stagger commitments so they expire on different dates and you never face a single cliff that pressures you into renewing the wrong size. The negotiation leverage that surrounds large renewals is covered in the cloud commitment negotiation guide, and the renewal posture itself in renewing AWS commitments from strength.
Frequently asked questions
When should I start an AWS commitment renewal?
Should I renew Savings Plans or Reserved Instances?
How much AWS coverage should I commit to at renewal?
Renew from a defensible forecast, not last year's bill
We rebuild your AWS forecast, size the renewal across Savings Plans and Reserved Instances, and ladder the purchase so you cover the baseline without stranding spend. 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.