Renewal Laddering
An AWS Reserved Instance ends on a clock, not a calendar.
A term doesn't end on a date. It ends at a timestamp, and if too many of yours land in the same week, one missed renewal turns into several. Here's what expiry concentration is, the target to ladder against, and what to do about a fleet that's already clustered.
First, the clock
An AWS term ends on a timestamp, not a date.
A Reserved Instance runs for a fixed number of seconds, counted from the moment you bought it, not from the start of a calendar day. A reservation purchased at 2:14 in the afternoon ends at 2:14 in the afternoon, on the last day of its term, not at midnight.
AWS states the term length in seconds, not days. A one-year Reserved Instance runs for exactly 31,536,000 seconds; a three-year term runs for exactly 94,608,000 seconds, both counted from the second you bought it. AWS's own Reserved Instances overview states both figures directly. RDS and ElastiCache reservations run the same one-year and three-year terms, bought and counted the same way.
When the clock runs out, nothing about the running instance changes. No restart, no downtime. AWS's own billing documentation is explicit: usage the reservation covered reverts to the standard on-demand rate, applied by the clock-hour, the same clock-hour system AWS uses to apply the reservation's discount in the first place.
A renewal deadline written as a bare date already lost precision an AWS reservation never had. Track the hour, not just the day.
Then, the shape
Your expiry dates have a shape.
Twelve reservations ending in twelve different months is one shape. Twelve reservations ending the same week is a very different shape, for the same total spend. The Expiry Check tool already builds a 12-month histogram of your own portfolio; concentration is what to look for in it.
Concentration is the share of committed annual spend whose term ends in a single month, or across a rolling three-month window. A high concentration means one review, one approval, and one purchase date carry most of the portfolio's renewal risk.
The concentrated shape commits 40% of a year's committed spend to a single month, and 46% to its worst quarter. The laddered shape spreads the identical total so no month tops 9%, and its worst quarter carries 26%, just above the 25% target below. Same commitment. Very different renewal risk.
Why it matters
A cluster costs more than the same reservations, spread out.
Three reservations ending in the same week share one review, one owner, and one approval window, tried three times against the same backlog.
AWS Cost Management offers an opt-in reservation expiration alert: an email 7, 30, or 60 days before term end, and again on the day itself.AWS documents the feature this way. Turning it on doesn't fix a cluster. It just sends the same short list of people several near-identical emails in the same week, and a full inbox is exactly the condition under which one of them gets missed.
A cluster is also a quota problem, not just a review problem. AWS caps new EC2 Reserved Instance purchases at 20 per Region and 20 per Availability Zone a month. A large renewal backlog can hit that purchase quota before it hits anyone's review calendar.
The fix
Build a ladder, not a pile.
Laddering means spreading purchase dates so that no single quarter carries an outsized share of the portfolio's term ends, and re-staggering a fleet that's already bunched up.
A practical checklist
Set a per-quarter ceiling
Keep roughly a quarter of committed annual spend ending in any one quarter. A fleet under that ceiling can absorb one missed renewal without it becoming a pattern.
Mix 1-year and 3-year terms
A 3-year term bought today lands its renewal three years later than a 1-year term bought the same day. Mixing terms re-staggers a fleet that already bunched up on one purchase date.
Buy short on purpose, sometimes
A 1-year term carries a smaller discount than a 3-year term, but it moves that reservation's term end to a date you choose. That trade is worth it exactly when the alternative is adding to an already-heavy quarter.
Split the next renewal, don't repeat the last one
A fleet that is already clustered stays clustered if every renewal re-buys on the date it lapsed. Split the next renewal across two or three purchase dates instead, and the cluster thins out one term at a time.
How this scales with you
The math doesn't care how big your fleet is. The fix looks different at each size.
A startup with six reservations has one cluster, and it is the whole fleet. There's no quarter to spread it across yet, so the fix is simpler: buy the next one on a different date than the last one, on purpose.
A growth-stage fleet hits its cluster right at quarter end, exactly when the review cycle is already busiest. Laddering here means picking renewal dates a few weeks off the calendar's own quarter boundary, not on it.
At this scale, laddering is a budget and procurement decision, not a habit. A purchase window needs a lead time long enough for approval, and a portfolio spread across many accounts needs one shared view of where the concentration actually sits.
Where Reserver fits
See your own shape, not an illustration.
The chart above is illustrative. Your own fleet's shape is real, and the Expiry Check tool already computes it from your own paste, free, nothing uploaded. Paste your own aws ... describe-reserved-* output into the Expiry Check, and the concentration read-out under its 12-month calendar names your heaviest month and your heaviest rolling quarter, with the dollar figures behind each one. Reserver's renewal autopilot and rules can then re-buy on the dates a ladder calls for, not just the date the last term happened to end. See features and the renewal playbook for the rest of the checklist a ladder sits on top of.
What is reservation laddering?
Reservation laddering means choosing purchase dates so that no single month or quarter carries a large share of a fleet's committed annual spend ending at once. Spreading term ends reduces renewal risk the same way spreading reservations across instance classes reduces coverage risk.
How much of my portfolio should expire in any one quarter?
A common target is no more than about 25% of committed annual spend ending in any single quarter. Above that, one missed renewal review affects a large share of the fleet at once.
My reservations already expire on the same date. What do I do?
Do not re-buy the whole cluster on the same date again. Split the next renewal across two or three purchase dates, mix 1-year and 3-year terms, and the cluster thins out one term at a time.
Does buying a shorter 1-year term ever make sense, even at a smaller discount?
Yes, when the reason is moving that reservation's term end away from an already-heavy quarter. Laddering is about spreading term ends, and a shorter term is one of the few ways to move one on purpose.
Does AWS warn me before a reservation expires?
AWS Cost Management offers an opt-in reservation expiration alert: an email 7, 30, or 60 days before term end, and again on the day itself. It is off until somebody turns it on, and it only ever notifies. A concentrated month still sends the same short list of people several alerts in the same week.
Is laddering only worth doing at a large fleet size?
No. A small fleet has less to spread, but the fix scales down too: buy the next reservation on a different date than the last one, on purpose, instead of repeating the same purchase day.
Sources, fetched and confirmed on 2026-09-06: EC2 Reserved Instances overview (term length, in seconds); how billing works with Reserved Instances; and reservation expiration alerts.
Stop overpaying for a steady fleet.
Reserver is in early access. Join the list and we'll onboard you as capacity opens up. Your first recommendation lands within minutes of connecting.