Azure gives you two main ways to pay less by committing up front.

A reservation gets you the deepest discount, but you are locking in a specific SKU in a specific region. A savings plan gives up some of that discount in exchange for freedom: you are only committing to spend a certain amount per hour on compute and database services, and it does not care which region you spend it in.

Until now, a reservation could move with you. If your infrastructure or database environment changed, or a workload had to move to a new region, you exchanged the reservation for one that matched where things had landed. That flexibility is why teams could commit early and adjust as the environment evolved.

That flexibility is changing. From February 1, 2027, you can no longer exchange a reservation for any service that a savings plan covers.

Neither product is changing. What is changing is how much room you have to adjust a commitment after your environment shifts, which means the order you make these decisions in matters a lot more than it used to.

What’s changing

Here is what is affected as of the announcement.

Compute: Azure Virtual Machines (including swapping between non-premium and premium storage), Azure Dedicated Host, and Azure App Service.

Databases: Azure Database for PostgreSQL, Azure Database for MySQL, Azure DocumentDB, Azure Cosmos DB, Azure SQL Database, and Azure SQL Managed Instance.

That list will grow. As savings plans start covering more services, reservations for those services automatically fall under the same rule. Products that are being retired are excluded, and so are clouds where savings plans are not offered.

Two details really matter.

• If you own a reservation for one of these services and you bought it before February 1, 2027, you get one final exchange after that date. Just one.


• Buy on or after that date and you get none.

Full details, including the FAQ, are in the official announcement: “Reservation exchanges for Azure services covered by savings plans end starting Feb. 1, 2027“.

What’s staying exactly the same

This is worth spelling out, because it is easy to read more into the announcement than is actually there. All of this still works.

• VM instance size flexibility is untouched.


• Cancelling a reservation is untouched.


• Trading a reservation in for a savings plan is still there.


• Buying and renewing reservations is still available, and still the right call for steady workloads.

Reservations are not going anywhere. The only thing changing is your ability to swap one for another when your environment moves underneath it.

The part most teams get backwards

You cannot think clearly about timing without this, and it is the thing people most often have wrong: reservations and savings plans are not a choice between two options. You can use both.

They stack, and they apply in a set order every hour.

1. Reservations go first, on anything they match.


2. The savings plan picks up what is left, up to your hourly commitment.


3. Whatever is still uncovered bills at pay-as-you-go, using your negotiated rate.

Here is one hour, made concrete. Say you have reservations covering $10 an hour of matching VMs, plus a savings plan committed at $5 an hour. In an hour where you use $18 of eligible compute, $10 gets reservation pricing, $5 gets savings plan pricing, and the last $3 bills pay-as-you-go. The savings plan did not fight the reservation for that spend. It caught the overflow.

Two things people assume that are not true. The terms do not have to match: a three-year reservation and a one-year savings plan work fine side by side. And you do not tag or assign anything. Once you buy a savings plan, it looks across whatever scope you bought it at and applies itself wherever it finds a fit.

That flexibility is the whole point. A savings plan ties you to an hourly amount, not to a SKU or a region. A reservation ties you to both. Before February 2027 that difference was mostly about how big a discount you got. After, it also decides how easily your commitment can follow the environment as it changes.

Three rules for buying from here on

1. Lean on savings plans while things are still moving

Before you commit to anything, ask what is going to change in the next ninety days. If a team is midway through centralizing their networking and is about to delete every per-subscription VPN gateway, any recommendation you generate this week will be wrong next month. Azure Advisor rescans every day and rewrites its recommendations as your environment shifts.

If a workload is mid-migration, mid-consolidation, or mid-anything, a savings plan gets you a similar discount without locking you in. Move it to a reservation once it is genuinely settled. A domain controller running around the clock in one region is the textbook reservation. Something still being actively built is not.

2. Start short, and know why that matters now

Three years gets you the best rate. Starting with one year and extending as you get more confident was always the sensible approach. Now it carries more weight, because a reservation can no longer be exchanged when your environment moves. If one stops matching, your options are to cancel it under the existing policy, or trade it in for a savings plan. That is the whole list.

3. Buy at the business-unit level, not the tenant level

Buy everything centrally and you take away each team’s ability to pick what suits their own workloads. Then, when a team wants more coverage than the central purchase gives them, they go and buy their own at subscription level, and now you are paying for the same thing twice. Buying per business unit also makes chargeback far easier, because the discount ends up sitting where the spending happens.

Clean up before you commit

There is a step that comes before all of this, and it is not new advice. Azure Advisor already flags unattached disks, idle virtual network gateways, and VMs that should be resized or switched off. If you have not done that sweep, “Identify your savings potential in Azure” walks through the tools properly.

What is new is what happens if you skip it. Leftover and idle resources do not just eat into your savings. They inflate the number you size your commitment against. Commit against a messy environment and you have just locked in one to three years of spend on resources that should not be running. Up to now, an exchange gave you a way to adjust that later.

Cleaning up used to be good housekeeping. Once you cannot exchange out of a reservation, it is genuinely about limiting risk.

The same goes for the workloads you are keeping. Switch off VMs outside business hours before you buy a reservation, not after. Reservations only pay off on workloads that run constantly, and once you have bought one you owe the money whether the VM is running or deallocated. Scaling up and never scaling back down is the same problem wearing a different hat.

How to check it actually worked

Your reservation and savings plan discounts show up on the invoice under amortized cost. Three columns tell the story.

• Pay-as-you-go price is the list price.


• Unit price is your negotiated discount, before reservations are applied.


• Effective price is what you genuinely paid once reservations and savings plans were counted.

There is no neat query for this. You read it off the invoice. It is the clunkiest part of the whole process and it is the first thing your finance partner will ask about, so get it into your reporting now rather than during your first chargeback cycle.

What to do in the next ninety days

1. List every active reservation you hold for an affected service.


2. Work out which ones no longer match the workload. Those are your candidates for that one remaining exchange.


3. Decide deliberately where that one exchange does the most good. 


4. Clean up orphaned disks, idle gateways, over-replicated storage, and scale-ups nobody scaled back down.


5. Re-baseline your commitment sizing against the tidied-up environment.


6. Buy at business-unit level, leaning toward savings plans anywhere the workload is still changing.

The takeaway

Reservations and savings plans both still work, and both still save you real money. What changes on February 1, 2027 is that a reservation can no longer be exchanged when your environment moves, so the decision has to be right at the point you make it rather than adjusted afterwards. That puts the weight on sequence: clean up first, size the commitment against what is actually running, use savings plans while a workload is still settling, and move to a reservation once it has stopped moving. 

The deadline is not something to panic about. It is a good excuse to finally do the bit most cost programs skip.