How to Fix: Azure VM AllocationFailed

The Scenario

You’re deploying a new Standard_D4s_v3 VM into an existing production workload, or triggering a scale-out event on a VMSS during peak traffic on a Tuesday afternoon. The deployment fails with a generic allocation error after a minute or two of waiting, leaving your deployment pipeline red.

Symptoms

Azure portal or CLI returns: {"code": "AllocationFailed", "message": "Allocation failed. We do not have sufficient capacity for the requested VM size in this region."}
VM creation or VMSS scale-out hangs for 60-120 seconds then fails with AllocationFailed
No other resource constraints (quota, permissions, network) are reported

Root Cause

Azure’s compute fabric cannot place the VM in the specified region or availability zone due to insufficient capacity for that specific VM SKU and configuration. This is a transient resource constraint on the Azure side, not a configuration error in your template. It typically happens in popular regions (e.g., East US, West Europe) or during periods of high demand.

Resolution (Step-by-Step)

Retry with the same configuration but a different availability zone
If you specified a zone, remove it or try a different one. This shifts the request to a different fault domain.

az vm create \
  --resource-group my-rg \
  --name my-vm \
  --image UbuntuLTS \
  --size Standard_D4s_v3 \
  --zone 2  # try 1, 2, or 3, or omit --zone entirely

Try a different VM size within the same family
Use a slightly larger or smaller SKU (e.g., D4s_v3 → D8s_v3 or D4s_v4). Azure often has capacity for adjacent sizes.
```
az vm create \
  --resource-group my-rg \
  --name my-vm \
  --image UbuntuLTS \
  --size Standard_D8s_v3
```

Deploy to a different region or paired region
Use a region with more available capacity. Check your latency requirements first.

az vm create \
  --resource-group my-rg \
  --name my-vm \
  --image UbuntuLTS \
  --size Standard_D4s_v3 \
  --location westeurope  # instead of eastus

Deploy as a proximity placement group (PPG) member
If you’re deploying multiple VMs that need to be close together, create a PPG first. This can sometimes help Azure’s scheduler find capacity.

az ppg create --name my-ppg --resource-group my-rg --location eastus
az vm create \
  --resource-group my-rg \
  --name my-vm \
  --image UbuntuLTS \
  --size Standard_D4s_v3 \
  --ppg my-ppg

Use reserved instances or capacity reservations
For critical workloads, purchase reserved capacity for the specific VM size and region. This guarantees allocation.
```
az reservation purchase \
  --reserved-resource-type VirtualMachines \
  --sku Standard_D4s_v3 \
  --location eastus \
  --quantity 5
```

Why This Sometimes Doesn’t Work

Even after trying all zones and adjacent sizes, you may still hit AllocationFailed if the entire region is saturated for that VM family. In that case, you must switch to a different VM family entirely (e.g., D series → E series) or use a different region. The error is transient—retrying 15-30 minutes later often succeeds as capacity frees up. Don’t keep hammering the same request; back off with exponential delay.

Verification

Confirm the VM is running and reachable:

az vm show --name my-vm --resource-group my-rg --query "provisioningState"
# Expected output: "Succeeded"
az vm list-ip-addresses --name my-vm --resource-group my-rg

Common Follow-up Questions

Q: Can I automate retry logic for AllocationFailed?
Yes. Wrap your deployment in a script that retries with exponential backoff (e.g., 30s, 60s, 120s) and alternates zones or sizes. Azure SDKs have built-in retry policies you can configure.

Q: Does this affect existing running VMs?
No. AllocationFailed only impacts new VM creation or scale-out operations. Existing VMs continue running normally. If a running VM fails over to another host (e.g., during Azure maintenance), it may experience a similar allocation failure on restart.

Q: How is this different from quota errors?
Quota errors (QuotaExceeded) mean you’ve hit your subscription limit for that VM family in the region. AllocationFailed means Azure itself doesn’t have capacity right now, even if you have quota available.

Prevent This in the Future

Proactive monitoring of deployment failures and capacity trends can help you catch allocation issues before they block critical deployments. Teams using Better Stack can set up alerts on Azure activity logs for AllocationFailed events and automate fallback deployments to alternative zones or regions. Set up uptime monitoring and alerts with Better Stack