Reserved Instances Are Expiring. Now What?

The default behavior is expensive

When a Reserved Instance expires, the workload it was covering reverts to on-demand pricing. There's no grace period, no warning pop-up, no automatic transition to a cheaper rate. One day you're paying the RI rate — say $0.038/hour for an m5.xlarge in us-east-1 — and the next day you're paying $0.192/hour. A 5x increase, applied silently to your bill.

For a single instance, the difference is about $1,350 per year. For an organization with 200 RIs expiring over the course of a year, the aggregate cost of even a few weeks of on-demand pricing between expiration and renewal adds up to tens of thousands of dollars. And that assumes someone notices. We've seen organizations run workloads at on-demand rates for months after RI expiration because nobody was tracking the expiration calendar.

The four options at expiration

Every expiring RI presents a decision with four possible outcomes. The right answer depends on usage patterns, flexibility requirements, and whether the workload itself is stable.

Option 1: Renew at current terms.If the workload is stable, the instance type hasn't changed, and you're confident it will run for another 1–3 years, renewal is straightforward. But “straightforward” doesn't mean “automatic.” Before renewing, verify that the instance type is still the right one. AWS regularly releases new instance generations with better price-performance. Renewing an m5.xlarge RI when you could migrate to m6i or m7i and get more compute per dollar is leaving money on the table.

Option 2: Convert to a Savings Plan.AWS Savings Plans offer more flexibility than RIs. A Compute Savings Plan applies across instance families, sizes, OS types, regions, and even across EC2, Fargate, and Lambda. The discount is slightly lower than an equivalent RI (typically 3–5% less), but the flexibility means the commitment stays utilized even as your infrastructure evolves. For workloads that might change instance type, region, or service over the commitment period, Savings Plans are usually the better instrument.

Option 3: Right-size before renewing.RI expiration is the natural inflection point to evaluate whether the underlying instance is correctly sized. If average CPU utilization is 15% and memory usage is 20%, you're paying for capacity you don't need. Right-size first — move to a smaller instance type — then purchase the new commitment against the right-sized workload. The savings compound: lower base cost plus the discount rate.

Option 4: Let it lapse.Not every RI should be renewed. If the workload is declining, migrating to a different service (containers, serverless), or scheduled for decommissioning, letting the RI lapse is the right call. The short-term cost of on-demand pricing is lower than the long-term cost of a 1-year commitment on a workload that won't exist in six months.

The 90-day pre-expiration window

The analysis for each expiring RI needs to happen 60–90 days before expiration. That window provides enough time to evaluate usage patterns (you need at least 30 days of data to establish a trend), run the right-sizing analysis, compare RI renewal terms against Savings Plan alternatives, and route the purchase decision through procurement if required.

Most organizations don't have a systematic process for this. The RI expiration date arrives, someone gets an AWS email notification (if they've set one up), and the decision is made reactively. Reactive decisions default to either auto-renew (the safe but suboptimal choice) or do nothing (the expensive choice).

A proper expiration management process looks like this: 90 days out, generate the list of expiring commitments with their current utilization. 60 days out, complete the analysis for each one (renew, convert, right-size, or lapse). 30 days out, execute the purchase decisions. On expiration day, verify that coverage is maintained with no gap.

What most teams get wrong

Auto-renewing everything.It feels safe, but it locks in last year's infrastructure decisions for another 1–3 years. AWS has released multiple new instance generations since your last RI purchase. Your workload characteristics have changed. Auto-renewal means you're paying for yesterday's infrastructure at a discount instead of paying less for today's infrastructure at a discount.

Evaluating RIs in isolation.Each RI expiration should be evaluated in the context of your full commitment portfolio. If you're already covered by Compute Savings Plans that have capacity, a new RI purchase might create redundant coverage. The portfolio view matters more than any individual instrument.

Ignoring Azure and GCP expirations. AWS RIs get the most attention because AWS tends to be the largest cloud spend. But Azure reservation expirations and GCP CUD renewals follow the same logic and the same pitfalls. A unified expiration calendar across all providers prevents the secondary clouds from bleeding money while everyone focuses on AWS.

The case for managed expiration management

A managed discount service handles the expiration lifecycle continuously. Every commitment is tracked, analyzed before expiration, and replaced with the optimal instrument — whether that's a renewed RI, a Savings Plan conversion, a right-sized commitment, or a short-term instrument that covers the workload while a migration is in progress.

The difference between managed and DIY approaches is most visible at expiration time. A managed service operates on a continuous cycle, adjusting coverage as workloads change. A DIY approach operates on the expiration calendar, reacting to deadlines instead of proactively optimizing the portfolio. When 50 RIs expire in the same quarter, the managed approach handles it without drama. The DIY approach turns it into a fire drill.