Capacity reservation group

Understand the concept

In plain English

A capacity reservation group is the Azure Compute container that holds one or more on-demand capacity reservations for virtual machines. It lets teams reserve VM capacity in a specific region or availability zone without committing to a one-year or three-year reserved instance term. In plain English, it is a way to make sure needed compute capacity is set aside for important workloads. VMs or scale sets reference the group so matching reserved capacity is available when the workload starts or scales.

Why it matters

Capacity reservation group matters because cloud capacity is not guaranteed at every moment for every VM size and zone. Critical workloads, disaster-recovery drills, seasonal demand, or regulated processing windows may need assurance that compute can be started when required. A group gives architects a placement container for those reservations while keeping control over duration. The tradeoff is cost and planning discipline: reserved capacity is charged while held, even if idle. Teams should use it for workloads where capacity assurance is worth the expense, and document which applications, VM sizes, zones, and business events justify the reservation. That evidence keeps accountability clear.

Official wording and source

A capacity reservation group is the Azure Compute container that holds one or more on-demand capacity reservations for virtual machines. Microsoft Learn places it in On-demand capacity reservation for Azure Virtual Machines; operators confirm scope, configuration, dependencies, and production impact.

Open Microsoft Learn

Technical context

Technically, a capacity reservation group is created before individual capacity reservations and is scoped to a region, with optional availability zones. Each reservation inside the group specifies VM size, quantity, and supported placement. VMs and compatible scale sets can be associated with the group so Azure applies the reserved capacity for matching instances. Operators inspect group location, zones, sharing settings, reservations, utilization, VM associations, quota, and errors through portal, ARM, Bicep, CLI, PowerShell, and Compute resource provider operations.

Exam context

Compare with

Virtual machine Managed disk

Where it is used

Where you see it

In the Azure portal, capacity reservation groups appear under Compute with region, availability zones, contained reservations, utilization, tags, and associated resources. for governance and incident response.
In ARM, Bicep, CLI, or PowerShell, the group appears as Microsoft.Compute/capacityReservationGroups with reservations, zones, sharing profile, and VM references. for governance and incident response.
In operations reviews, group evidence appears beside quota checks, disaster-recovery plans, scale-set settings, reserved capacity utilization, and cost justification notes. for governance and incident response.

Common situations

Create a capacity reservation group before adding reservations for critical VM sizes.
List reservations and utilization during disaster-recovery or capacity planning reviews.
Confirm a VM or scale set is associated with the intended reservation group.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Scenario 01 Capacity reservation group for claims surge Scenario, objectives, solution, measured impact, and takeaway.

Scenario

EverTrust Insurance, a national insurer, needed guaranteed VM capacity for storm-season claims processing in a specific Azure region and availability zone.

Goals

Reserve 120 D-series VM instances before storm season
Associate scale-set capacity with the approved reservation group
Meet a four-hour claims surge recovery objective
Release unused capacity after the risk window

Approach using Capacity reservation group

The infrastructure team created a capacity reservation group in the target region and zone, then added reservations for the exact VM size used by the claims-processing scale set. Bicep templates associated the scale set with the group, and runbooks verified quota, reservation utilization, and zone alignment before every storm drill. Azure Monitor dashboards tracked running instances, reserved capacity, and application queue depth. FinOps added owner tags and review dates so unused reservations would be resized or deleted after storm season rather than silently carrying cost. The team reviewed results with application owners before closing the change record. Support notes documented rollback ownership and business approval.

Potential outcomes

Storm drill scale-out reached target capacity in 38 minutes
Claims backlog stayed below the four-hour recovery objective
Reservation utilization averaged 91 percent during active events
Unused capacity was released within five business days after season close

What to learn

A capacity reservation group gives critical VM workloads a planned capacity safety net when availability matters more than idle-capacity cost.

Scenario 02 Capacity reservation group for semiconductor batch windows Scenario, objectives, solution, measured impact, and takeaway.

Scenario

QuartzFab Systems, a semiconductor analytics company, ran monthly simulation batches that required scarce memory-optimized VMs in one Azure region.

Goals

Reserve capacity for 80 memory-optimized VMs during batch week
Avoid failed VM allocation at job start
Track utilization against reserved capacity
Remove reservations when workloads moved to a new SKU

Approach using Capacity reservation group

Architects created a capacity reservation group scoped to the production analytics region, with reservations for the required memory-optimized VM size. Batch orchestration templates associated VMs with the group during approved simulation windows. Operators checked capacity reservation utilization, job queue depth, and VM allocation errors before starting each run. The team tagged the group with BatchWindow, BusinessOwner, and ReviewDate. When simulation software moved to a newer SKU, the runbook required creating a new reservation group and deleting the old reservations after validation. The team reviewed results with application owners before closing the change record. Support notes documented rollback ownership and business approval. Risks were reviewed.

Potential outcomes

Monthly batch allocation failures dropped from five events to zero
Simulation start delay fell from three hours to 20 minutes
Reserved capacity utilization reached 88 percent during batch windows
Obsolete reservations were removed before the next billing cycle

What to learn

Capacity reservation groups help scheduled compute-heavy workloads start reliably when a specific VM size must be available.

Scenario 03 Capacity reservation group for public safety failover Scenario, objectives, solution, measured impact, and takeaway.

Scenario

Harbor County Emergency Services, a public safety agency, needed compute capacity reserved for a regional failover of dispatch support systems.

Goals

Reserve failover VM capacity in the paired region
Validate association during quarterly recovery exercises
Keep ownership and cost justification visible to finance
Avoid confusing capacity reservation with discount purchasing

Approach using Capacity reservation group

The cloud team built a capacity reservation group in the recovery region with zone-aligned reservations for dispatch application VMs. Recovery templates referenced the group when creating standby VMs during exercises. The runbook separated capacity assurance from reserved-instance discount planning, making clear that the group existed to guarantee placement during emergencies. Operators verified quota, reservation quantity, VM size, and deployment success in each drill. Finance received monthly utilization and justification reports, and the group carried tags for service owner, recovery tier, and review cadence. The team reviewed results with application owners before closing the change record. Support notes documented rollback ownership and business approval.

Potential outcomes

Quarterly failover exercises allocated all required VMs successfully
Recovery environment build time improved from 2.5 hours to 47 minutes
Finance approved continued reservation based on documented public-safety risk
No discount-plan reporting confused the capacity reservation purpose

What to learn

A capacity reservation group is a reliability tool for planned VM availability, not merely a purchasing discount.

Azure CLI

Use CLI, ARM, or PowerShell for capacity reservation groups when you need precise evidence of region, zone, reservation size, utilization, and VM association.

Useful for

Create a capacity reservation group before adding reservations for critical VM sizes.
List reservations and utilization during disaster-recovery or capacity planning reviews.
Confirm a VM or scale set is associated with the intended reservation group.

Before you run a command

Confirm tenant, subscription, scope, resource group, region, and environment before collecting or changing production evidence.
Use least-privileged access and avoid exposing keys, tokens, personal data, billing details, or confidential topology in output.
Know whether the command is read-only, mutating, cost-impacting, or security-impacting before running it in production.

What the output tells you

Output confirms whether the live configuration exists at the expected Azure scope and matches the approved design.
Returned properties, metrics, or logs help separate healthy service behavior from drift, missing configuration, or workload symptoms.
Differences between environments provide evidence for rollback, tuning, support escalation, audit review, or owner follow-up.

Mapped commands

Vm operations

direct

az vm list --resource-group <resource-group>

az vmdiscoverCompute

az vm show --name <vm-name> --resource-group <resource-group>

az vmdiscoverCompute

az vm create --name <vm-name> --resource-group <resource-group> --image <image>

az vmprovisionCompute

az vm start --name <vm-name> --resource-group <resource-group>

az vmoperateCompute

az vm stop --name <vm-name> --resource-group <resource-group>

az vmoperateCompute

Architecture context

Capacity reservation group matters because cloud capacity is not guaranteed at every moment for every VM size and zone. Critical workloads, disaster-recovery drills, seasonal demand, or regulated processing windows may need assurance that compute can be started when required. A group gives architects a placement container for those reservations while keeping control over duration. The tradeoff is cost and planning discipline: reserved capacity is charged while held, even if idle. Teams should use it for workloads where capacity assurance is worth the expense, and document which applications, VM sizes, zones, and business events justify the reservation. That evidence keeps accountability clear.

Security: Security for a capacity reservation group focuses on who can reserve scarce compute capacity, associate workloads, and change placement. Limit permissions through RBAC and require approvals for production groups because capacity reservations can affect cost, regional availability planning, and workload placement. Tags should identify owner, application, environment, and business reason without exposing sensitive project details. Review whether associated VMs also meet identity, patching, disk encryption, network, and monitoring standards. The group itself does not secure the VM; it only influences capacity. Audit create, update, association, and deletion events so capacity cannot be hoarded or redirected silently. Review exceptions after each change.
Cost: Cost is significant because on-demand capacity reservations are charged for the reserved compute whether or not a VM is running against them, although applicable discounts may reduce the effective rate. Holding idle reservations can become expensive quickly, especially for large sizes or many zones. FinOps should track utilization, owner, business justification, and expiration review. Reservations are not the same as reserved instances or savings plans; they address capacity assurance, not automatically long-term discount commitment. The best cost practice is to reserve only what the business truly needs, measure consumption, and release capacity promptly when risk has passed. Review outcomes after each billing cycle.
Reliability: Reliability is the main value of a capacity reservation group. It helps ensure a workload can start or scale into a chosen region or zone when capacity might otherwise be constrained. This is useful for disaster recovery, critical batch windows, high-priority application tiers, and planned events. Operators should test VM association, failover steps, quota, zone alignment, and scale-set behavior before the reservation is needed. Reliability also requires monitoring utilization so reservations are not empty or mismatched. A reservation for the wrong VM size, zone, or subscription does not protect the workload. Runbooks should explain how capacity is consumed. Test the recovery path regularly.
Performance: Performance is not improved by a capacity reservation group in the sense of faster CPUs or lower latency. Its performance value is ensuring that the right VM capacity is available when workload demand requires it. This can protect batch completion windows, recovery-time objectives, and scale-out plans that depend on specific sizes or zones. Operators should still benchmark the VM SKU, storage, network, and application design separately. If a workload scales into reserved capacity but is bottlenecked by disk, database, or network limits, the reservation only solved placement. Performance planning should combine capacity assurance with workload sizing evidence. Document baseline measurements before tuning.
Operations: Operationally, capacity reservation groups need inventory, ownership, utilization review, and event-based planning. Record region, zone, VM size, instance count, associated workloads, expected use window, quota dependency, and approval reason. Before maintenance or disaster-recovery tests, confirm that target VMs reference the correct group and that capacity is available. After an event, review utilization and decide whether to keep, resize, share, or delete reservations. Include capacity reservations in change planning because VM size changes, zone movement, or scale-set updates can break the match. Good operations prevent expensive reserved capacity from becoming invisible shelfware. Keep owners and evidence current. Keep owners and evidence current.

Common mistakes

Confusing capacity reservations with reserved instances or savings plan discounts.
Reserving capacity in the wrong zone, VM size, or subscription for the workload.
Leaving idle reservations running after an event, migration, or test completes.