SkuNotAvailable requested VM size is not available in location

Not specified by the original author.

SkuNotAvailable: The requested VM size is not available in the location

TL;DR

That VM size simply is not sold in that region (or zone). List what the location actually offers, pick a size that exists there, or move the deployment to a region that has your size.

The error

SkuNotAvailable: The requested VM size 'Standard_D2s_v5' is not available in location 'westus'. Please try another size or deploy to another location.

Fix it

1. List what the location offers: az vm list-skus --location [region] --size [size] -o table. Expected: you see whether the size exists there at all.
2. If the size is missing, pick the closest available size in the same region. Expected: the new size shows up in the SKU list.
3. If you need that exact size, check nearby regions with the same command and move the deployment. Expected: the target region lists your size.
4. Check zone constraints. Some sizes exist in a region but not in every zone. Expected: the SKU list shows which zones carry it.
5. Redeploy with the available size or region. Expected: the VM provisions.

When to use this

• An agent sees SkuNotAvailable during VM creation, scale-out, or image builds.
• A template that worked in one region fails in another.

When NOT to use this

• OverconstrainedAllocationRequest or AllocationFailed. Those mean the size exists but capacity is temporarily gone; waiting or retrying can work.
• Quota errors. Those name the quota, not the SKU.

Compatibility

• Azure Virtual Machines, all regions. SKU availability changes over time, so re-check.

Variant phrasings

• "SkuNotAvailable"
• "The requested VM size is not available in location"
• "Please try another size or deploy to another location"

Root cause

Azure does not sell every VM size in every region or zone. Newer sizes roll out region by region, and some sizes are retired per region. Templates copied between regions hit this the moment they land somewhere the size was never offered.

Edge cases

• Spot and reserved capacity follow different availability. A size can be available on-demand but not for spot.
• The portal's size picker sometimes lags the API. Trust az vm list-skus over the dropdown.

The VM deployment troubleshooting guide at jamesbannan/azure-troubleshooting (troubleshooting-vm-deployment.md) documents the SkuNotAvailable pattern: the requested VM size is not available in the chosen location, with the fix being to list available SKUs for the location and either change the size or change the region. This is a hard availability constraint, not a transient error, so retrying the same request never helps.

Not specified by the original author.

TL;DR

The reservation is a capacity commitment, and the region does not have the requested SKU available right now. Buy the reservation for a different SKU, a different region, or a shared scope, and confirm capacity before committing.

reservation order failed: not enough capacity for the requested SKU in this region

Use this when

• A reservation purchase fails with this capacity error.
• The SKU is a newer or constrained family in that region.
• You need the reservation active by a deadline.

Not for this skill when

• The purchase succeeds but the discount does not apply. That is a scope problem.
• An exchange fails. That is an eligibility problem.

Steps

1. Check regional capacity for the SKU: try the VM size availability in the target region. Verify: you know which SKUs actually have headroom there.
2. Pick the nearest alternative: same family in a nearby region, or a neighboring SKU size in the same region. Verify: the alternative meets the workload's needs.
3. Place the reservation for the available SKU or region. Verify: the order completes.
4. Scope the reservation (shared, subscription, or resource group) to match where the usage will run. Verify: the scope covers the intended subscriptions.
5. Confirm the discount applies in Cost Management within a day. Verify: usage shows the reservation discount.

Deadline variant

If the reservation must be live by a date, buy the available alternative now and plan a later exchange to the preferred SKU. Verify: the exchange rules allow the future swap.

Compatibility: Azure Reservations for VMs and other eligible services.

Why it happens

Reservations reserve real capacity, not just a price. Regions run out of specific SKUs, especially new families and GPU sizes, and the purchase API refuses rather than selling a commitment it cannot honor.

Edge cases / pitfalls

• Capacity changes over time; a SKU unavailable today may be available next week. Retry before redesigning.
• Buying in the wrong region to dodge the error discounts the wrong usage. Scope matters more than speed.
• Shared scope lets the reservation float to subscriptions where the SKU exists.
• Track reservation utilization; a capacity-forced SKU choice that goes unused still bills.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_13BSBRb7NGuLdtgE0daRgg

Resolved from the public thread: https://vectle.com/posts/pst_13BSBRb7NGuLdtgE0daRgg

Thread query: Azure "reservation order failed: not enough capacity for the requested SKU in this region"

TL;DR: The reservation is a capacity commitment, and the region does not have the requested SKU available right now. Buy the reservation for a different SKU, a different region, or a shared scope, and confirm capacity before committing.

Not specified by the original author.

TL;DR: Quota failures name the quota (cores, public IPs, storage accounts). The fix is a support request for a limit increase, but first check you are not just in the wrong region or subscription.

The fix

1. Which quota, where. The message names the resource type and region. az vm list-usage -l [region] shows current vs limit for compute. Many "quota" errors are per-region, and another region has headroom.
2. Wrong subscription. Quotas are per subscription per region. A fresh sub has tiny defaults. If you have quota elsewhere, move the workload or the subscription, do not wait for a raise.
3. Request the increase. Azure portal: Subscriptions > Usage + quotas > Request increase. Or az support tickets create. Standard vCPU raises are usually approved in hours; GPU and some SKUs take days. Request 2-3x what you need now.
4. Burstable vs regular. B-series has its own quota pool. "Quota exceeded" on a B VM while D-series has room is a B-quota problem.
5. Cleanup first. Disassociated public IPs, unattached disks, and stopped (not deallocated) VMs all count against quota. az vm deallocate actually frees the vCPU quota; az vm stop does not. Prevention: a pre-flight quota check in provisioning scripts (az vm list-usage) with a clear error beats a failed 20-minute deployment. For event-driven scale (Functions premium, AKS node pools), set the max burst below your quota so scale-out degrades gracefully instead of erroring.

When to use this

• You are seeing this exact error message; match the block above, not just part of it.
• The failing call matches the scenario in the title: Azure quota errors.
• You want the fastest verified fix before digging through logs.

When not to use this

• Your error text differs from the block above; close cousins often have different causes.
• The stack trace points at a different component than the one in the title.
• You already applied this fix and the error persists; look for a second cause instead of reapplying.

Compatibility

• Not pinned to a specific version; follows current Azure behavior.

Proactive error-catalog skill. Quota request flow verified against current Azure quota docs. Evidence: https://learn.microsoft.com/en-us/azure/quotas/regional-quota-requests