Azure Reserved VM Instances Retired: Your 2026 Exit Guide

Your Azure bill hasn’t changed yet. That’s the problem.

On July 1, 2026, Microsoft stopped selling and renewing Reserved VM Instances for a long list of VM series. Nothing turned off. No VM rebooted, no alert fired, no deployment broke. The reservations you already own keep applying their discount right up to their expiration date, exactly as they always did. And then, on whatever unremarkable Tuesday your three-year Esv3 reservation happens to lapse, the discount evaporates and those instances start billing at pay-as-you-go.

The auto-renew toggle is still sitting there in the portal. For these series, it no longer does anything.

That gap — between the retirement date and the day your particular reservation expires — is the entire story. It might be next month. It might be 2029. The decision is the same either way, and it has to happen before the meter changes, not after you spot the spike in a monthly review.

What actually changed

Two buckets, and people keep conflating them.

One-year RIs are no longer purchasable or renewable for Av2, Amv2, Bv1, D, Ds, Dv2, Dsv2, F, Fs, Fsv2, G, Gs, Ls, and Lsv2.

Both one-year and three-year RIs are gone for Dv3, Dsv3, Ev3, and Esv3.

Notice the asymmetry. If you run Dsv2, you can still buy a three-year reservation today. If you run Dsv3 — a newer series — you can’t buy anything. That reads backwards until you realize Microsoft is steering the v3 general-purpose fleet toward savings plans rather than propping up instance-locked commitments on a generation it wants to sunset.

Three things did not change, and they matter as much as what did:

• Existing reservations run to full term. July 1 terminated nothing.
• The VMs themselves aren’t retired. Dv3, Dsv3, Ev3 and Esv3 are still available to deploy. Only the reservation product went away.
• Reservations are a billing construct. Nothing about your running workload is affected. This is a finance event wearing an infrastructure costume.

If you renewed before the cutoff, that renewal is honored for its full term. Some teams got a three-year Esv3 reservation in on June 30 and bought themselves until mid-2029. Good for them. That door is closed now.

Audit your exposure in fifteen minutes

Portal path: Reservations, filter Product type to Virtual Machines, then read the VM family and Reservation expiration date columns. Anything in the two lists above is exposed.

From the CLI, if you’d rather have it in a spreadsheet:

# List reservation orders, then enumerate reservations within each
az reservations reservation-order list \
  --query "[].{id:name, term:term, expiry:expiryDate}" -o table
 
az reservations reservation list \
  --reservation-order-id <order-id> \
  --query "[].{sku:sku.name, qty:properties.quantity, state:properties.provisioningState}" -o table

Then do the part most people skip: check utilization. In Cost Management, open the reservation utilization view. A reservation sitting at 60% utilization was already leaking money, and the expiration is a good excuse to fix the sizing rather than recommit to the same wrong number.

Sort the result by expiration date. Anything expiring in the next two quarters is a live problem. Anything expiring in 2028 is a calendar entry, not a crisis — but put it in the calendar, because nobody remembers this in eighteen months.

Exit 1: Azure savings plan for compute

You commit to a fixed hourly spend, in dollars, for one or three years. That commitment gets consumed by eligible compute across VM families, regions, and even other services like App Service and Container Instances. Spend past your commitment bills at pay-as-you-go.

The headline discount is lower. Microsoft and the FinOps vendors quote savings plans reaching roughly 65% off pay-as-you-go against about 72% for reservations — call it a 7-point flexibility premium at the extremes. Those are best-case marketing maxima on three-year terms for specific SKUs, and your actual delta on a general-purpose one-year commitment will be narrower. Don’t plan against the headline; pull your own rates.

Here’s the part that costs people real money. A savings plan covers spend, not instances, and unused commitment is not refunded or rolled over. If you commit at your average hourly compute spend, every hour below average burns commitment you don’t recover. Commit at your floor — the trough of your daily and weekly cycle — and let the peaks bill at pay-as-you-go or sit under separate reservations. Under-committing costs you a little discount. Over-committing costs you cash, every hour, for three years.

This is the right default if your VM footprint is going to change. Scaling, re-architecting, moving regions, adopting containers — all of it keeps working under a savings plan and none of it is protected by an instance-locked RI.

Exit 2: Move to current-generation SKUs

The obvious pitch is price-performance. Microsoft claims Dv5-series VMs cut cost per transaction by up to 31% and deliver up to 1.45x the throughput of the older D-series, and independent testing puts AMD-based Dasv5 roughly 11% cheaper than the Intel equivalents for workloads without Intel-specific dependencies.

But the reason to actually do this is subtler: v5 and v6 series still have reservations available. Migrating off Dv3 doesn’t just get you faster silicon, it puts instance-locked commitment pricing back on the table. If you’re the kind of shop that runs steady-state workloads and genuinely prefers the deeper RI discount, modernizing is the only path that keeps that option open. Staying on Dv3 means savings plans or nothing, forever.

The migration targets Microsoft recommends out of Dv3/Dsv3 are Dsv5, Ddsv5, Dasv5, Dadsv5, and the v6 equivalents.

Now the trap, and it will bite someone on your team. Dv5 and Dsv5 have no local temporary disk. Dv3 did. If anything on that box writes to /mnt on Linux or D: on Windows — SQL Server tempdb, a page file, a scratch directory some batch job assumed would always be there — resizing from Dsv3 to Dsv5 silently removes the disk out from under it. The Dd variants (Ddsv5, Dadsv5) are the ones with temp storage. Check before you resize, not after.

The other thing to check is Windows licensing. If you’re bringing licenses under Azure Hybrid Benefit, core counts drive the license math, and a “free” performance upgrade that lands you on more vCPUs isn’t free at all.

Exit 3: Do nothing, on purpose

Take a reservation that was saving you 45% and let it expire without a replacement, and the compute line for those instances goes up by roughly 80%. Not 45% — the discount was off the pay-as-you-go rate, so removing it moves you back up by the reciprocal. That arithmetic surprises people in budget meetings.

Sometimes it’s still correct:

• The workload is scheduled for decommission before or near the expiration date.
• It’s dev/test that could just be deallocated nights and weekends, which beats any commitment discount.
• The footprint is small enough that the engineering hours to migrate exceed the annual savings. Two D2s_v3 instances are not worth a sprint.

Microsoft’s own documentation is unusually blunt here: this “should be a conscious decision, not an accidental outcome.” Which is exactly what happens when the auto-renew toggle you set in 2023 becomes a no-op and nobody tells the person who owns the budget.

The exchange rules nobody reads

Two escape hatches that don’t show up in most coverage of this change.

Trading an RI in for a savings plan has no deadline. It’s self-service, it’s available any time, and it works on the reservations you’re holding right now. You don’t have to wait for expiration to make the switch — if you’re carrying a Dv3 reservation with eighteen months left and you know the fleet is changing, you can convert today.

Compute reservation exchanges are still alive. Microsoft planned to end exchanges of instance series and regions for VM reservations on January 1, 2024, then extended the grace period indefinitely, promising at least six months’ notice before it actually closes. So you can exchange a Dsv3 reservation into a Dsv5 reservation and keep instance-locked pricing on modern hardware. You obviously cannot exchange into a series that’s no longer purchasable, which makes exchange-and-modernize a single move rather than two.

Refunds exist too, capped at $50,000 USD per rolling twelve months, prorated, and Microsoft reserves the right to apply an early termination fee. Check the current terms before you count on that number.

Picking your exit

Two commitment vehicles can stack. A reservation covering your baseline plus a savings plan absorbing the variable layer is a perfectly sensible structure, and it’s how most mature Azure estates end up.

Compared to AWS

AWS went through this arc earlier and landed differently. Standard RIs still exist and still offer the deepest discount, Convertible RIs occupy the flexible middle, and Compute Savings Plans have become the default recommendation for most teams. AWS never removed the RI option from a live instance family the way Azure just did — it let the discount structures compete and watched savings plans win on their own.

Azure has effectively skipped that step for these fourteen-plus series. The practical consequence for anyone running multi-cloud: your Azure commitment strategy now has less room to be instance-specific than your AWS one, and the FinOps tooling you use to model this needs to know the difference. If you’re building that comparison out, the AWS savings plans vs reserved instances vs spot breakdown covers the other side, and the cloud cost platform comparison covers the tools that model both.

The next ninety days

Week one, run the audit and sort by expiration date. Anything lapsing inside two quarters goes on the board now.

Weeks two through four, model each exposed workload against all three exits with your real rates, not the marketing maxima. Check every candidate VM for temp-disk dependencies before you promise anyone a resize.

Month two, execute on whatever expires first. Trade-ins and exchanges are self-service and reversible-ish; savings plan commitments are not, so size those at the trough.

Month three, put a calendar reminder ninety days before every remaining expiration date, assigned to a named person. The failure mode here isn’t picking the wrong exit. It’s that the reservation expires on a day nobody was watching, the bill goes up 80% for one instance family, and it takes two billing cycles before anyone connects it to a decision made three years ago.

Go look at your reservation expiration dates. It takes fifteen minutes, and roughly half the teams that do it find something expiring sooner than they assumed.

Verified against Microsoft’s transition guide and reservation exchange policy as of July 2026. Discount percentages are vendor-quoted maxima — pull your own rates from Cost Management before committing.