Configuring Reserved VM Instances for Azure: reducing costs by up to 72%

Why cloud costs grow without Azure Reserved VM Instances

Almost any cloud estate grows iteratively: prod, staging environments, database replicas, machines for one-off migrations. Some of them run 24/7, although they actually need 8–10 hours on weekdays, while staging environments are simply idle outside working hours.

Pay-as-you-go means that the bill changes with load. This results in an unpredictable cloud workload profile: one month is cheaper, another more expensive, and planning the budget based on the previous period is pointless.

Azure Reserved VM Instances are about something else: a discount of up to 72% in exchange for a commitment to a size family, region, and term. You fix in advance how much compute capacity you are taking and for what term, and the provider charges less for it.

But reserving virtual machines stops working when it is estimated "by eye".

If the workload profile fluctuates, and the wrong family or size is reserved, the difference turns into stranded capacity: the entire reserved volume is paid for, while the workload goes past it — the discount cannot be transferred to another size or region without flexibility options.

Suboptimal resource consumption — oversized instances, idle time outside working hours, machines forgotten after migration — is paid for just like useful work. A reservation does not provide a discount for this: it only multiplies an already-made decision.

So the order is reversed: first inventory and analysis of actual consumption over a long period, then calculation of what volume a reservation actually pays off for. How this works is covered below.

What reservation provides: measurable effect

Reservation in Microsoft Azure provides a discount not at the moment of purchase, but at the moment when the share of covered hours matches the real workload profile.

Before starting work, we capture this profile over a period: which instance families run 24/7, which live for hours, and where idle time persists.

Without such a picture, a reservation turns into paying for idle hours, and the reduction in total cost of ownership turns out to be negative.

Share of covered hours

The main measurable metric is how many hours of the stable part of the workload are covered by the reservation. The working range is 70–85%: below that, the discount is lost; above that, the risk of paying for unused capacity grows.

We calculate this for each instance group separately, not as an average across the subscription, otherwise stable services mask one-off tasks.

Infrastructure cost forecast

After separating the workload into constant and variable, the forecast becomes a function of the number of reserved instances, not of peaks.

We hand the variable part over to autoscaling: it is paid at standard rates, but its share of the total bill stops being decisive and fluctuates predictably.

Exchange and cancellation of reservations

A reservation is tied to a family and region, so we build in a margin for migration: some are set up with exchange enabled, the rest for configurations that do not change.

This reduces the cost of a forecasting error: changing plans does not require rebuilding the entire purchasing scheme.

Predictability of subscription quotas

A reservation does not expand subscription limits, but it makes planning them deterministic — you can see in advance what volume of compute resources and in which regions will be needed for the next period.

We check limits before purchasing so that the discount does not remain unused due to a quota denial.

Reservation modes in Azure: comparison of options

Reservation in Azure is not a single option but several models with different scopes, and they are not interchangeable.

The choice is determined by three things: how homogeneous the VM fleet is, whether there is a hard binding to an availability zone, and how often sizes and families change.

The advice "take a long reservation for the entire fleet" in practice leads to part of the paid capacity sitting idle.

The difference between the options is what exactly is fixed. A zonal reservation ties capacity to a specific zone; a regional reservation applies to the entire region but does not guarantee capacity in a specific zone.

Flexible reservation exchange is a separate layer on top of the chosen model: it determines whether the unused remainder can be reused when the workload profile changes.

In practice, a combination is more often used: a regional reservation as the base and flexible exchange for changes. We verify the model against the workload profile and scaling settings before fixing anything.

Implementation stages: from workload audit to handover of procedures

Reservation does not start with a purchase but with measurements: without hourly consumption series, any reservation allocation scheme relies on guesswork. Below is the order of work, after which procedures remain, not a one-time setup.

1. Cloud workload audit. We capture consumption history in Azure by subscriptions and machine groups, separate baseline workload from peak and one-off runs, and flag unstable workloads that are not suitable for reservation.

2. Reservation profile calculation. Based on the stable core of the workload, we determine machine families, volume, and term — so that the commitment does not end up larger than actual consumption.

3. Reservation allocation scheme. We distribute capacity across subscriptions and environments and decide where the reservation is shared and where it is tied to a specific owner.

4. Configuration and scope. We create reservations, bind them to the required scopes, and define the application order so that the commitment covers the stable part of the fleet, not random runs.

5. Post-configuration effect check. We compare actual charges with the expected picture: where the reservation was not fully applied and where it sat unused — and redistribute the remainder.

6. Handover of procedures. We provide the reservation map, the rule for changes as the fleet grows, and a checklist for reviewing terms — the solution can be maintained without us.

Configurations, schemes, and procedures after implementation

A reservation is not a one-time purchase but a managed object that lives together with the infrastructure.

After implementation, the customer is left not with a set of screenshots but with a working framework: which subscriptions the reserved instances are tied to, who reviews them and by what rule, and where the documentation is stored. Below is what we hand over to your team.

• Reservation allocation scheme: which machine families, sizes, and regions are covered, how the remainder is distributed across subscriptions and environments, and what happens when a new workload appears.
• Reservation management procedure: review frequency, utilization thresholds, and the procedure for changing and exchanging the unused part.
• Subscription access policies: roles at the management group level, who is authorized to change a reservation, and who can only view reporting.
• Infrastructure documentation: a map of subscriptions and environments, the link between reservations and specific machine groups, and the procedure for configuration edits.
• Monitoring dashboard: coverage by subscription and family, deviation from the plan, and an alert when the workload has moved out from under the reservation.
• Review rules: the procedure before scaling — a new region, fleet growth, a change in workload profile.

All of this is versioned in your repository, so maintenance is not tied to us. Describe the task — we will come back with an estimate and a plan.

Practice: consumption profile before and after reservation

Before: a flat baseline and peak shortfalls

The consumption profile was captured from metrics over several months, not one day: the service has a flat 24/7 baseline and short peaks during deployment.

Diagnostics showed that about eight out of ten machines run continuously and their load is predictable — that is, a significant part of the fleet had been paid for years at the pay-as-you-go rate.

The second problem was not about costs: during release hours, there was not enough free quota for the required machine family in the region, deployment failed with an allocation error, and the rollout moved to the next window.

After: baseline layer under commitment, peaks — on actual consumption

The fleet was divided into two layers.

The baseline — predictable cores under 24/7 load — was covered by an Azure reservation for a long term in a specific region and family: the discount applies only to a matching configuration, so the family was chosen based on metrics, not "for future growth." The peak layer was left on demand — it is needed for hours, and there is no point in tying it up with a commitment.

The share of machine-hours covered by the reservation came out to about three quarters, the rest on actual consumption. Compute costs fell by almost three times with the same volume of releases.

The class of failures related to quota shortages disappeared: capacity for reservable families is fixed in advance, and deployment during peak hours no longer competes for the free limit in the region.

How reservation differs from a savings plan and what to choose

In Microsoft Azure, both models are a prepaid commitment for a term, but they are tied to different things. A reservation is fixed to a specific machine family and region: the discount is deeper, but the choice is limited.

A savings plan applies to the compute rate and automatically applies to what actually runs in the fleet.

The practical difference is visible with variable workloads. If you change the machine generation, distribute services across availability zones, or move to another region, the unused part of the reservation does not carry over to new resources.

In such a situation, a savings plan continues to cover a share of consumption, and the commitment does not sit idle.

The decision is made based on the consumption profile, not the size of the discount. If the baseline is stable and clear for the entire term, a reservation gives the maximum.

If the fleet is heterogeneous or migrations are ahead, it is safer to cover only the share that does not change with a plan — then a family change does not turn into a lost commitment.

We analyze consumption history by families, regions, and operating hours, cut off one-off peaks, and show which part of the baseline to cover with a reservation and which to leave flexible. The scheme is then reviewed as the fleet changes — it changes faster than the term expires.

Technical objections: what is important to check in advance

Reserved VM Instances in Azure provide a discount on compute resources in exchange for a commitment to a machine family, region, and term. Therefore, technical objections concern not the size of the discount but flexibility: what happens if the workload profile changes. Below are the doubts we resolve before purchase, not after.

How is a reservation distributed across subscriptions and environments?

A reservation works within the boundaries of the selected billing scope. If it is one subscription, machines in a neighboring subscription will not count, even when the family and region match.

We fix the scope in advance, verify machine sizes, and allocate the reservation by groups: production baseline separately, test environments separately.

We do not include environments that are shut down at night in the calculation — for them, the discount does not justify the loss of flexibility.

How to tell that a reservation is sitting idle?

We calculate the coverage share: how many reservation hours went to machines actually running, and how this changed from month to month. We set an alert for a drop in coverage — otherwise, growth or migration of environments turns into an unnoticed loss.

Separately, we maintain a quarterly review rule: we compare the workload profile with what was assumed at purchase.

Let's discuss the task: what is needed to calculate a reservation

So that the reservation calculation relies on actual data, not industry averages, we start with a pre-implementation audit: we look at what actually runs, what sits idle, and how the workload changes throughout the year.

Based on the results, we come back with an estimate, a reservation work plan, and a calculation of for what term and under which machine families a Reserved VM Instances reservation in Azure pays off.

What to prepare for the conversation:

• an export of virtual machines for several months: configurations, regions, availability zones, environment tags;
• daily and weekly load profile — where the peaks are, where the night and weekend dips are;
• a list of continuously running machines and those that are rarely started: reserving them is usually unprofitable;
• information about existing reservations and their expiration dates, so as not to pay twice for the same thing;
• a change plan: migrations, machine generation changes, service decommissioning;
• fault tolerance and support level requirements agreed with the cloud provider;
• the person responsible for infrastructure and for the department budget — the one who will make the decision on the coverage scheme.

Next, we check what could get in the way: subscription type, access rights, machine family restrictions, and already made commitments.

Let's discuss the task specifically — show us what data you are ready to provide, and we will come back with an estimate and an implementation plan.