Start with a plain definition, then add the details one layer at a time.

A Reserved Instance, in Azure usually called a reservation, is a commitment to use a specific Azure resource for a fixed term, either one year or three years. In exchange for this commitment, Azure charges a discounted rate compared with normal pay-as-you-go prices. The most famous example is the reserved virtual machine instance, but reservations also exist for many other services, such as databases, storage, and more.

It helps to understand what a reservation is not. It is not a physical machine set aside for you. It is not a new resource that you create and run. It is a billing discount that Azure automatically applies to matching usage, hour by hour. You keep creating and running your virtual machines or databases as usual. Each hour, Azure checks whether the running resource matches your reservation, and if so, the discounted rate is applied.

Both sides of the deal gain something.

Pay-as-you-go pricing is flexible but carries the highest rate per hour. Many real workloads, however, are not flexible at all. A company’s order system, its database, or its internal portal may run all day, every day, for years. Paying the top rate for something that never stops is wasteful.

For Azure, a commitment is valuable too. When customers promise to use capacity for one or three years, Azure can plan its data centers better, so it shares part of that benefit as a discount.

The discount is applied automatically, one hour at a time.

When you buy a reservation, you choose what to reserve, such as a certain virtual machine size in a certain region, how many units, the term, and the scope. Azure then looks at your usage every hour. If a running resource matches the reservation, the usage is covered by the reservation and the discounted price applies. If no matching resource runs during an hour, the reserved capacity for that hour is simply unused, and you cannot carry it over to another hour.

Any usage beyond what the reservation covers is billed at normal pay-as-you-go rates. So the reservation covers a fixed amount, and everything above that amount stays flexible.

flowchart TD
  H["Each hour: running resources in scope"] --> M{"Matches a reservation?"}
  M -->|Yes, within reserved quantity| D["Covered by reservation: discounted"]
  M -->|Yes, but above reserved quantity| P["Billed at pay-as-you-go rate"]
  M -->|No match| P
  R["Reserved capacity with no matching usage this hour"] --> W["Hour is wasted, cannot be carried over"]
        

Reservations cover far more than virtual machines.

Learn these words once and the rest of the topic becomes much easier.

flowchart TD
  RO["Reservation Order: purchase and payment"] --> R1["Reservation A: VM size, region, quantity, scope"]
  RO --> R2["Reservation B: other settings"]
  R1 --> SC["Scope: where the discount can apply"]
  SC --> U["Matching usage in that scope"]
  U --> UT["Utilization report"]
        

Scope is one of the most important and most misunderstood settings.

The scope decides which resources can use the reservation discount. A narrow scope gives control but risks leaving the reservation unused. A broad scope makes it easier to find matching usage, so utilization tends to be higher.

flowchart LR
  RES["Reservation with Shared scope"] --> S1["Subscription: Finance"]
  RES --> S2["Subscription: Retail"]
  RES --> S3["Subscription: Data Platform"]
  S1 --> V1["Matching VMs get discount"]
  S2 --> V2["Matching VMs get discount"]
  S3 --> V3["Matching VMs get discount"]
        

A reservation does not always need to match a machine size exactly.

For many virtual machine families, Azure groups sizes into a series where each size has a ratio, for example a machine twice as large counts as two units. With instance size flexibility turned on, a reservation for one size in the group can cover other sizes in the same group, in proportion to the ratio. A single larger reservation might cover two smaller machines, or two smaller reservations might cover one large machine.

A reservation lowers one part of the cost, not the whole bill.

flowchart TD
  VM["One Windows virtual machine running for an hour"] --> C["Compute charge: covered by reservation"]
  VM --> L["Windows license charge: separate, or removed by Hybrid Benefit"]
  VM --> D["Disks: billed separately"]
  VM --> N["Network and data transfer: billed separately"]
        

Two similar names, two completely different jobs.

A reservation, which is the subject of this guide, is a billing discount. It does not guarantee that Azure will have a machine available in a particular zone when you ask for one. A capacity reservation is a different feature that reserves compute capacity in a region or zone so you can be sure to get machines when needed, and it is billed at the normal rate for that capacity, whether you run machines on it or not. You can combine them: a billing reservation can discount the cost of the reserved capacity.

Two choices at checkout change both the saving and the risk.

Choosing the term

A three-year term usually gives a bigger discount than a one-year term, but you are committing for longer. The longer the term, the more important it is that the workload really will exist for that whole time, with similar size and location.

Choosing how to pay

For most reservation types, you can pay for the whole commitment upfront, or pay in equal monthly installments. In many cases, the total price is the same either way, so monthly payment simply spreads the cash flow without extra interest, although this can vary by product and agreement. Upfront payment may be easier to account for, while monthly payment keeps cash free. Check the checkout screen and current rules.

The art of reservations is to cover the floor, not the ceiling.

Look at the usage of your machines and databases across weeks and months. There is usually a level of usage that never drops, even on your quietest day. That level is the steady base. Above it, usage varies with demand, seasons, and projects. A reservation is best used to cover the steady base, because it will be fully used every hour. The variable part is better left to pay-as-you-go pricing, autoscaling, or spot capacity.

flowchart TD
  TOT["Total usage over a month"] --> BASE["Steady base: always running"]
  TOT --> VAR["Variable part: peaks and short jobs"]
  BASE --> RES["Cover with reservations"]
  VAR --> PAYG["Pay-as-you-go and autoscale"]
  VAR --> SPOT["Spot for interruptible work"]
        

Purchasing is simple, but the permissions and choices need care.

A reservation that is bought and forgotten can quietly lose money.

The key measure is utilization, which is the percentage of reserved capacity that was matched by running resources. A utilization of ninety percent or more is generally healthy. A figure that is much lower means that you are paying for capacity you do not use, so you should act. The Azure portal shows utilization for each reservation, over different time periods, and also shows which resources used it.

What to do when utilization is low

Reservations are commitments, but the terms offer some limited room to adjust.

Historically, Azure allowed some changes after purchase: exchanging a reservation for another of equal or greater value, and returning a reservation for a refund within certain limits, which could include a cap per period. Policies differ by product and have changed over time, including announced changes for compute reservations, with some dates postponed. Because these rules shift, treat the following as general ideas and check the current official policy before relying on any of them.

Azure offers several ways to save. Each fits a different kind of workload.

flowchart TD
  Q1{"Is the workload steady and always on?"}
  Q1 -->|No, unpredictable or short-lived| PAYG["Pay-as-you-go or autoscale"]
  Q1 -->|Yes| Q2{"Will size family and region stay the same?"}
  Q2 -->|Yes| RI["Reservation: highest discount"]
  Q2 -->|Not sure, may change| SP["Savings plan: flexible commitment"]
  Q1 -->|Interruptible batch work| SPOT["Spot capacity"]
        

The same idea works beyond virtual machines, with a few differences.

Reservations change how costs appear, which can confuse people at first.

With pay-as-you-go, each hour of usage shows a cost line. With a reservation, the covered usage shows as zero or reduced cost, and the purchase itself appears as a separate charge, either once or monthly. Looking only at actual cost can make a month with a purchase look expensive and following months look cheap, even though the real daily cost is steady.

A reservation is a financial commitment, so it needs an owner and a process.

flowchart LR
  A["Analyze usage and recommendations"] --> B["Review and approve purchase"]
  B --> C["Buy reservation with chosen scope"]
  C --> D["Monitor utilization and alerts"]
  D --> E["Adjust scope or quantity"]
  E --> F["Plan renewal or replacement before expiry"]
  F --> A
        

Cloud designs evolve, and a long commitment must survive those changes.

A three-year reservation assumes that your workload will look broadly the same for three years. But applications are often redesigned, moved to containers, rebuilt as serverless, or migrated between regions. These changes can leave a reservation without matching usage.

See how different organizations use reservations well.

An honest look helps you decide with open eyes.

Habits that keep your reservations profitable and your finance team happy.

No. It is a billing discount, not a physical machine and not a capacity guarantee. You still create and run your resources normally, and Azure applies the discount automatically to matching usage. If you need guaranteed capacity, look at capacity reservations as a separate feature.

You still pay for the full reservation. Unused reserved hours cannot be carried forward, so they are wasted. That is why you should reserve only your steady base, monitor utilization, and adjust scope or workloads if it falls.

The extra usage is billed at normal pay-as-you-go rates. The reservation covers only the quantity you bought, so peaks are handled by regular pricing, autoscaling, or other discount options.

If instance size flexibility applies, you can change sizes within the same family and region, and the reservation keeps applying by ratio. For other changes, you may need an exchange, which depends on current policy and product, so check the latest rules.

No. A virtual machine reservation covers the base compute cost. The Windows software charge is separate, unless you use Azure Hybrid Benefit with eligible licenses. Disks, networking, and data transfer are billed separately as well.

Choose a reservation when you are confident the exact resource family and region will stay the same, and you want the highest discount. Choose a savings plan when your compute may change in size, service, or region but your total hourly spend is steady. Many organizations use both, with reservations for the most stable systems.

Some products have offered limited exchange and refund options, with caps, fees, or conditions, and policies have changed over time. Do not assume you can cancel freely. Read the current official policy before buying, and treat the reservation as a real commitment.

Check utilization in the portal, and compare the amortized cost of covered usage with what the same usage would have cost at pay-as-you-go rates. Healthy utilization and a clear net saving mean it is working. Low utilization means you should act by widening the scope or adjusting workloads.

Azure Reserved Instances, or reservations, are one- or three-year commitments that lower the price of steady workloads. They are a billing discount, not a special machine and not a guarantee of capacity. Each hour, Azure matches eligible running resources to your reservation within its scope, applies the discounted rate to matching usage, bills extra usage at normal rates, and loses any unused reserved hours. Scope, instance size flexibility, term, and payment style shape the outcome. Reservations cover the compute part of a machine, not licenses, disks, or networking, and can be combined with Hybrid Benefit. The craft is to right-size first, reserve only the steady base, buy gradually, monitor utilization, assign clear ownership, and plan renewals, while remembering that exchange and refund rules are limited and can change. Used with discipline, reservations turn predictable usage into predictable savings.