If you run production workloads on EC2, you already know the pain of long-term commitments in a world where instance families, architectures, and scaling patterns change every quarter. Convertible Reserved Instances (often called Convertible RIs, or CRIs) are AWS’s answer to that problem. They give you a meaningful discount in exchange for a 1 or 3 year commitment, while letting you reshape that commitment as your needs evolve.
This article breaks down what CRIs are, how they work, where they shine, and where they can still go sideways without smart management.
What is a Convertible Reserved Instance?
A Convertible Reserved Instance is an EC2 Reserved Instance offering class that provides a discounted hourly rate compared to On-Demand pricing, in exchange for committing to a specific EC2 configuration for a fixed term. Unlike Standard RIs, CRIs can be exchanged for a different configuration later.
Key properties:
- Term: 1 year or 3 years.
- Scope: You buy them for a specific AWS Region, and the discount applies to eligible usage in that region. You cannot exchange across regions.
- Discount vs flexibility: CRIs typically discount less than Standard RIs, but more than On-Demand. The tradeoff is that you get reconfiguration flexibility.
- Payment options: No Upfront, Partial Upfront, or All Upfront, each affecting effective rate and cash flow.
The CRI exchange mechanism: what you can change
The defining feature of CRIs is that AWS lets you exchange one or more CRIs for a new CRI with different attributes, as long as the new reservation has an equal or higher total value than what you are exchanging. Exchanges are allowed as many times as you want.
You can change:
- Instance family and type (example: m5 to m7g, c6i to c7a).
- Operating system (example: Linux to Windows).
- Tenancy (Default, Dedicated).
What you cannot change:
- Region. CRIs are region-bound. If workloads move regions, the commitment can become stranded.
- The equal or higher value rule. You cannot exchange “down” to something cheaper. If the target configuration is lower value, AWS will adjust the quantity so the new CRI is still equal or higher value overall.
How the value rule works in practice:
- AWS compares list value of your remaining term: upfront paid plus remaining hourly value.
- If the new CRI is more expensive, you may pay a prorated true-up.
- If you are exchanging multiple CRIs with different end dates, the new CRI inherits the latest end date among them.
Think of this as a controlled refactor of your commitment, not a cancellation.
CRIs vs Standard RIs vs Savings Plans
Commitment choices are really about how much uncertainty you need to absorb.
- Standard RIs: biggest discount, minimal flexibility. You cannot exchange a Standard RI.
- Convertible RIs: good discount with the ability to reshape the instance attributes later, but still tied to a region and requires exchanges to adapt.
- Compute Savings Plans: commitment is in dollars per hour rather than a specific instance. They often provide flexibility similar to CRIs without needing explicit exchanges, but do not cover non-compute RI scopes like RDS.
A simple way to choose:
- If usage is stable and unlikely to change families or OS, Standard RIs can be great.
- If you expect family shifts, resizing, or architectural changes over a year or more, CRIs are often the safer RI path.
- If you want flexibility across many compute shapes and services, Savings Plans may be better.
Real-world CRI use cases
Here are the patterns CRIs were built for:
- Family or architecture migration
- You reserve m5 today, then your platform adopts Graviton or a newer Intel or AMD family.
- You exchange to the new family and keep discounts rolling.
- Workloads that resize over time
- You start with r6i.2xlarge, then rightsizing and autoscaling nudge you to r6i.xlarge or r7i.
- CRI exchanges let your commitment follow those shifts without buying new commitments from scratch.
- Long-lived services with evolving requirements
- Databases, message brokers, or control-plane components that will run for years, but not necessarily on the same shape.
- CRIs keep you covered while the infra matures.
The hidden operational cost of CRIs
Despite the flexibility, CRIs have real management friction:
- You have to notice drift. AWS will not automatically exchange for you. When usage migrates to a different family, your CRIs can underutilize quietly.
- The value rule can be tricky. It’s easy to end up overcommitting to meet the equal value constraint, especially during a downshift.
- Region lock-in is still real. Even with exchanges, regional moves strand commitments.
- At scale, exchanges become a full-time job. Large orgs juggle dozens to thousands of CRIs across accounts.
This is why many teams buy CRIs for flexibility, then still fail to capture effective savings.
Best practices for using CRIs well
- Target conservative coverage first
- Start with your stable baseline, not your peak.
- CRIs are forgiving, but not magic.
- Review utilization and exchange opportunities on cadence
- Weekly or biweekly checks work well for growing environments.
- Look for family drift, OS drift, and sustained size changes.
- Prefer staggered buys
- Avoid one giant purchase.
- Smaller tranches reduce the blast radius if forecasts are wrong.
- Use CRIs alongside forecasting
- Forecasting tells you how much to commit.
- CRIs let you reshape those commits when reality differs.
How smart commitment management upgrades CRIs
Done manually, CRIs are flexible but fragile. A smart commitment manager can turn CRIs into a living commitment layer by:
- Detecting workload drift early and recommending or executing exchanges.
- Keeping utilization high without forcing you to overbuy.
- Coordinating exchanges across accounts and families while respecting the value rule.
- Blending CRIs with Savings Plans and On-Demand in a way that preserves optionality.
The result is a commitment posture that preserves discounts while matching how modern AWS usage actually changes.
Wrap-up
Convertible Reserved Instances are AWS’s most flexible RI commitment. They let you keep long-term discounts while changing instance family, OS, and tenancy as your environment evolves, provided you stay within the equal-or-higher value constraint and the same region.
If your infra shifts often, CRIs are a strong building block. They just need continuous attention or automation to prevent savings leakage.