Azure reservations vs savings plans for .NET workloads
Buy a reservation for the part of a .NET estate that has been flat for months and will not change: the production SQL tier and the App Service instances that never scale in. Put a savings plan on top for compute that is still moving between sizes, services or regions. Rightsize before either, because a commitment lowers the rate on whatever you run, including the waste. And decide soon how much rigidity you can live with: reservations bought after February 1, 2027 can no longer be exchanged for services a savings plan also covers.
The rules below were checked against Microsoft's documentation in September 2026. The discounts quoted are Microsoft's published maximums, not what a given estate will see.
The two commitments side by side
Both run for one or three years, both can be paid up front or monthly for the same total, and both are billing discounts only: nothing about the running resources changes.
| Feature | Reservation | Savings plan |
|---|---|---|
| What you commit to | A specific SKU or instance family in a specific region | A fixed dollar amount per hour of eligible usage |
| Where the discount lands | Only on resources that match the SKU, region and scope | On any eligible service, in any region, up to the hourly amount |
| Published maximum discount | Up to 72% off pay-as-you-go | Up to 65% off pay-as-you-go |
| When the workload changes | The reservation sits partly unused until exchanged or refunded | The discount moves to whatever eligible usage exists that hour |
| Unused commitment | Lost for that hour | Lost for that hour |
| Ways out | Exchange (restricted from February 2027), refund within a $50,000 rolling 12-month cap, or trade-in for a savings plan | None. It cannot be canceled, refunded or exchanged |
When both exist, Azure applies the reservation first and the savings plan to what is left, so the two never compete for the same usage.
What each one actually commits you to
A reservation is a bet on a shape. You tell Microsoft you will run, say, a given Premium v3 App Service size in East US for three years, and in return that shape gets the deepest discount Azure offers. If the platform moves to a different tier, family or region, the reservation keeps billing and the new resources pay full price.
A savings plan is a bet on a spend level. You commit to an hourly dollar amount and Azure discounts eligible usage, highest discount first, until that amount is used up each hour. It does not care which service, size or region generated the usage. The price of that freedom is a somewhat lower discount and no exit at all.
There are now two savings plans. The savings plan for compute covers virtual machines, App Service, the Azure Functions Premium plan, Container Apps, Container Instances and Dedicated Host. The newer savings plan for databases covers Azure SQL Database (including serverless and Hyperscale), SQL Managed Instance, Cosmos DB and Azure Database for PostgreSQL and MySQL. Neither covers storage, networking or software charges.
A .NET estate, piece by piece
App Service. Reservations exist only for Premium v3 and the Isolated tier, and Microsoft quotes savings of up to 55% per instance on Premium v3. Many .NET estates still sit on Standard or Premium v2, where no commitment applies at all. Moving to Premium v3 is usually the first step: it is often cheaper per unit of compute on its own, and it is the tier the discounts attach to. Reserve the instance count that never scales in. Leave the autoscaled instances above it to a savings plan or to pay-as-you-go.
Azure SQL. Reserved capacity applies to the vCore purchasing model, not to DTU tiers and not to serverless. A production database or elastic pool whose vCore count has not moved in a year is the textbook reservation. Databases that are being consolidated, moved to serverless or resized belong under the savings plan for databases, or under nothing until they settle.
Azure Functions. The Premium plan is covered by the savings plan for compute. The Consumption plan is pay-per-execution and has nothing to commit to, which is as it should be.
Virtual machines. Both options apply. Reservations carry instance size flexibility within a VM family, so a reservation survives a resize inside the family but not a move to a different one. If a modernization plan is going to retire those VMs in favor of App Service or containers, a savings plan follows the workload across that move and a reservation does not.
Containers. Container Apps and Container Instances are covered by the savings plan for compute, which suits them: container workloads change size and shape more often than anything else in the estate.
The order that works
Microsoft's own guidance puts it in this sequence, and it matches what holds up in practice. First rightsize: remove idle resources, fix non-production sizing, consolidate plans. A discount on an oversized footprint locks the oversizing in for up to three years. Then repair existing commitments: exchange reservations that no longer match while that is still possible, or trade them in for a savings plan. Then buy reservations for what is stable and well understood. Last, add a savings plan sized to the clean baseline that remains.
The common mistake is the reverse order: a three-year reservation bought from a portal recommendation before anyone had checked whether the footprint was right. It is leak number two in where mid-market Azure bills actually leak money.
The exits, and what changes on February 1, 2027
Refunds. A reservation can be canceled for a prorated refund, but the total canceled commitment cannot exceed $50,000 in a rolling 12-month window per billing profile or enrollment. Microsoft does not currently charge an early termination fee and says it may introduce one of 12% in the future. For a mid-market estate, that cap is smaller than it sounds: one three-year reservation on a production data tier can exceed it.
Exchanges. Today a compute or SQL reservation can be exchanged for another in the same product family, with a new term and an equal or larger commitment. That is what has made reservations tolerable for platforms in motion. It is ending: reservations purchased after February 1, 2027 are not eligible for exchange when the service is also covered by a savings plan, which includes virtual machines, App Service and Azure SQL Database. Reservations purchased before that date keep one final exchange.
Trade-ins. Compute reservations can be traded in for a compute savings plan, and database reservations for a database savings plan, as long as the new commitment is at least the remaining value of the old one. Microsoft has said this does not change. It only works in one direction: a savings plan cannot be traded for anything.
The practical effect: from February 2027 a new reservation is genuinely rigid for its whole term. That tilts the decision toward savings plans for anything that is not flat, and toward one-year terms for reservations on platforms with a modernization plan.
How much to commit
Both commitments are use-it-or-lose-it by the hour, so the number that matters is not average spend but the floor: the hourly eligible spend you reach even at three in the morning on a holiday. Commit to a level at or just under that floor. Everything above it keeps paying the pay-as-you-go rate, and that is fine, because that is the part of the bill that can still shrink.
Treat the portal's purchase recommendations as a starting point. They are computed from the last 7, 30 and 60 days of usage, and they do not know that staging is about to be resized, that two App Service plans are about to be merged, or that a service is moving regions next quarter. Your roadmap is the input the recommendation engine does not have.
For the finance conversation: up-front and monthly payment cost the same in total, so paying monthly keeps the cash unless there is an Azure prepayment balance to draw down. A one-year term gives up some discount in exchange for a decision you get to make again in twelve months. On a platform that is being modernized, that option is usually worth more than the difference.
Related questions
Which saves more, an Azure reservation or a savings plan?
A fully used reservation saves more: Microsoft publishes up to 72% off pay-as-you-go for reservations and up to 65% for savings plans. A partly used reservation can easily save less than a savings plan would have, which is why the stability of the workload decides it, not the headline discount.
Can we have reservations and a savings plan at the same time?
Yes, and most estates with both steady and changing workloads should. Azure applies reservations first and the savings plan to the remaining eligible usage. Buy one, wait about a week for the recommendations to update, then size the other.
Can an Azure savings plan be canceled?
No. A savings plan cannot be canceled, refunded or exchanged, and its hourly commitment cannot be reduced. You can change its scope. Size it to the floor of your usage, not the average.
Does a savings plan cover Azure SQL Database?
The savings plan for compute does not. The separate savings plan for databases does, along with SQL Managed Instance, Cosmos DB and Azure Database for PostgreSQL and MySQL. Reserved capacity remains available for vCore-based Azure SQL when the tier is stable.
Should we commit before or after rightsizing?
After. A commitment lowers the rate on what you run, so committing first locks the oversized footprint in for the term. Rightsize, let the new baseline run for a few weeks, then commit against it.
Next step
We’re on top of things and aim to respond to all inquiries within 24 hours.
Imhauser Technologies
McLean, VA
United States
Available on-site across the DC metro, Tysons, Reston, Arlington, and Washington, DC, as well as hybrid and remote worldwide.