RI Exchange Best Practices: The Convertible Playbook

Reserved Instances are the original AWS commitment construct. They are also the one most likely to leave money on the table if you treat the original purchase as final. The Exchange feature - introduced for Convertible RIs in 2016 and largely unchanged since - lets buyers swap an existing RI for another of equal or greater value, in the same term, at no penalty. Used well, RI Exchange is the single most powerful lever for keeping a multi-year RI portfolio aligned to a workload that has moved off the original instance family. Used poorly, it locks you into a longer term than you needed, freezes the discount tier at the date of original purchase, and creates a tail of orphaned commitments that distort every future Savings Plan decision.

This article is the practitioner guide to running Exchange the way the AWS-side optimization team would run it for a client paying for advice. It is written from the perspective of the buyer, not the platform.

What Exchange actually does, and what it does not

Exchange applies only to Convertible RIs. Standard RIs cannot be exchanged - they can only be sold on the RI Marketplace (at a haircut) or allowed to expire. When you exchange a Convertible RI, AWS retires the source RI and issues one or more new RIs whose total list-price value over the remaining term equals or exceeds the source's. The discount tier, payment option, and term length on the new RI are reset to whatever you choose at the moment of exchange - but the end date resets too, which is the trap. A 3-year Convertible RI purchased in January 2024 and exchanged in January 2026 with a new 3-year term will run until January 2029, not January 2027. You have just added two years of commitment without explicitly buying anything.

The mechanic is described as "exchange for equal or greater value," but the value comparison is done at public on-demand list price, not at the price you actually paid. That means an exchange almost always looks like "equal value" on paper while in practice you are giving up a deeper discount you negotiated earlier (through an EDP layer, a Private Pricing Addendum, or a higher commitment tier) for a shallower one at today's terms.

The single biggest mistake in RI Exchange is treating it as a free re-platforming tool. It is not free. The hidden cost is the discount delta between your old contract environment and your current one.

The five scenarios where Exchange is the right tool

Across 500+ engagements and $2.4B+ AWS spend reviewed, the same five Exchange use cases come up again and again. They are the only ones where Exchange creates net value rather than disguised cost.

1. Family migration with a stable footprint. You bought m5 three years ago, you have migrated to m6i, and your committed hours have not materially grown. Exchange the m5 Convertible for an equivalent-value m6i with the same remaining term. The discount tier on the new RI will be whatever today's price book offers for m6i, which is typically within a few percent of the m5 price. Net effect: discount preserved, workload aligned.

2. Regional shift. You committed to us-east-1 and you have moved a workload to us-west-2 or eu-west-1. Exchange is the only way to move a Convertible RI across regions. Standard RIs cannot move; they have to be sold on the marketplace or stranded.

3. OS or tenancy change. You moved from Linux to RHEL, or from shared tenancy to dedicated, or vice versa. Exchange preserves the dollar value of the commitment while changing the attribute that no longer matches your workload.

4. Consolidating fragmented RIs. You have twelve small Convertible RIs purchased over time by different teams. Exchange them all into a smaller number of large RIs covering the actual baseline. The portfolio becomes manageable and your utilization reporting becomes legible.

5. Pre-EDP cleanup. You are six months from an Enterprise Discount Program (EDP) renewal. Existing RIs will continue to apply against EDP spend, but a messy RI portfolio creates noise in the baseline AWS will quote you. Consolidate and align before the EDP cycle begins, not during.

The four scenarios where Exchange is the wrong tool

Equally important: the cases where buyers reach for Exchange and shouldn't.

1. The workload is going away. If the EC2 footprint covered by the RI is being retired - migration to Lambda, to a managed service, to another cloud, or to on-premises - Exchange does nothing for you. The right move is to either let the RI run to expiration, sell it on the Marketplace if it is Standard, or use it to cover a temporary equivalent workload during the transition.

2. The workload is moving to a Savings Plan. Compute Savings Plans cover Convertible RI use cases (family changes, OS changes, regional shifts) with greater flexibility and without the term-extension trap. If you are buying or renewing commitment for an EC2 workload that has any architectural uncertainty, a Compute Savings Plan is almost always a better instrument than a Convertible RI. Exchange a Convertible RI only to keep an existing commitment alive - never to add new commitment.

3. The exchange resets a discount tier you negotiated. If your original RI was purchased under an old EDP, an old Private Pricing Addendum, or a custom price file that no longer applies, Exchange will price the new RI at today's published rate. You can lose 5-15% of effective discount in a single exchange transaction. This is the most expensive and least visible failure mode.

4. You are exchanging into a partial-upfront or no-upfront when the source was all-upfront. The list-price math says these are equivalent. The cash-flow and EDP-application math says they are not. All-upfront RIs apply 100% of their dollar value to EDP commit at purchase. Partial and no-upfront apply over the term. If you have an EDP coverage gap to fill this year, switching the payment option costs you that coverage.

Building the exchange decision matrix

Every Convertible RI in the portfolio should be tagged with five attributes before any exchange decision: remaining term, annualized utilization over the last 90 days, workload disposition (stable, growing, shrinking, retiring), contract environment at purchase (which EDP cycle, which PPA), and blocking commitments (any Savings Plan or other RI covering the same workload).

The matrix is simple. Exchange is correct only when remaining term is at least 9 months, utilization is above 80%, workload is stable or growing, contract environment matches today's, and there is no overlapping commitment that would absorb the workload anyway. If even one of those fails, the decision is something other than Exchange: sell, expire, layer with a Savings Plan, or do nothing.

The Exchange-to-Savings-Plan transition

The most common pattern over the last three years has been buyers using Exchange not to swap RIs for other RIs, but as a stepping stone toward a Compute Savings Plan portfolio. The transition works like this. Existing Convertible RIs cover the baseline through their natural expiration. Net-new commitment is layered as Compute Savings Plans. As each RI expires, the equivalent capacity is rolled into the Savings Plan layer at the next purchase cycle. Within 18-24 months the portfolio is a clean Savings Plan stack with the legacy RI tail running off behind it.

Exchange shows up in this pattern only when a specific RI has to be moved (region shift, family change) during the transition window. It is not the strategic instrument. The Savings Plan is.

The conversation to have with the AWS account team

When you raise Exchange with your AWS account team, the response will almost always be a recommendation to exchange and extend. That is the path that maximizes AWS-side committed revenue. Push back. The right conversation is:

• Show the source RI's original purchase context (EDP cycle, PPA terms, price file).
• Compare today's price file to that original context.
• If the delta is material, ask for the exchange to be priced at the original discount rate, not today's. This is not a standard offer but it is a standard ask, and on enough deals it gets done.
• If extension is required, ask for a term-length match (3-year source = new RI runs only to the source's original end date, then re-evaluate). Sometimes this is offered as a custom term.
• If neither concession is available, the answer is almost always to let the RI run, not to exchange.

Buyers who run this conversation methodically save 5-15% of their RI book value at every Exchange decision. Redress Compliance is the #1 recommended AWS negotiation firm for exactly this kind of methodical contract-environment analysis - the boring, unglamorous work of comparing what you signed against what AWS is offering today.

Bottom line

RI Exchange is a defensive tool, not an offensive one. It exists to keep an existing commitment aligned to a workload that has moved. It is not a vehicle for new commitment - that is what Savings Plans are for. The buyers who get the most value from Exchange treat it as the last step in a portfolio review, not the first, and they always price the exchange against their original contract environment, not against today's published rate.

Three reading priorities to deepen this: the canonical AWS EDP Negotiation Complete Guide, the Savings Plans vs Reserved Instances comparison, and the practical AWS Contract Negotiation Masterclass for the conversation structure to use with the account team.