Azure VM AllocationFailed: Fix when capacity is full

Seeing AllocationFailed when deploying an Azure VM is frustrating. You pick a size, hit deploy, and Azure says nope — no room. Don't panic. The fix isn't complicated, but you need to move fast because capacity can shift by the hour.

The quick fix: change your approach

Azure's allocation failure means the specific combination of VM size and region (or availability set) has no free servers right now. The most reliable fix is to pick a different VM size in the same family. For example, if you tried Standard_D2s_v3, try Standard_D4s_v3 or even Standard_D2_v3 (without the 's' for premium storage). The exact SKU matters less than getting something running.

Here's the step-by-step:

1. Go to the Azure portal and start a new VM deployment.
2. On the Basics tab, leave everything the same — resource group, region, image.
3. Under Size, click Change size.
4. In the size picker, choose a different VM size from the same family. I usually go one size up or down. For instance, if Standard_D2s_v3 failed, try Standard_D4s_v3 or Standard_B2ms (the Burstable series often has more capacity).
5. Click Review + create and deploy.

After you hit deploy, you should see the validation pass and deployment start. If it throws AllocationFailed again, move to the next option.

Second option: use a different availability zone

If you're deploying to a region that supports availability zones (like East US 2 or West Europe), force the VM into a specific zone. Azure's allocation logic spreads load across zones, so one zone might be full while another has space.

Here's how:

1. While creating the VM, go to the Advanced tab.
2. Under Availability options, pick Availability zone.
3. Select Zone 1. Deploy. If it fails, try Zone 2, then Zone 3.
4. You don't need to change the VM size for this — the zone change alone often works.

After selecting a zone and deploying, you should see the VM provision normally. If all three zones fail, the region is genuinely tight on that SKU.

Third option: change the region

This one stings because it means moving your data, but it's the surest fix. Pick a neighboring Azure region that has the same VM SKU available. For example, if East US is full, try East US 2 or Central US. You can check SKU availability per region using Azure CLI:

az vm list-skus --location eastus --size Standard_D2s_v3 --all --output table

That command shows whether that SKU is available in East US. Run it for a few regions. Pick one with Available in the output. Then deploy there.

Why it worked (the boring but useful explanation)

Azure doesn't guarantee infinite capacity for any single VM size in any region. When you request a VM, Azure's orchestrator checks if the physical servers in that cluster have room. If every server in that cluster is running at capacity, you get AllocationFailed. By changing the VM size, you target a different cluster that might have free servers. By changing the zone, you're targeting a different physical datacenter inside the same region. By changing the region, you're moving to a whole different set of datacenters.

The real trigger for this error usually happens during peak hours — Monday mornings, end-of-quarter pushes, or after a major Azure outage when everyone redeploys at once. I've seen it spike during Black Friday sales for retail customers.

Less common variations of the same issue

Not all allocation failures look the same. Here are three I've seen:

1. Resizing an existing VM fails

You try to resize a running VM to a larger size and Azure says AllocationFailed. The fix: stop (deallocate) the VM first. In the portal, go to the VM, click Stop, confirm. Wait for the status to show Stopped (deallocated). Then resize. After the VM stops, Azure releases its physical server slot and gives you a fresh allocation attempt.

2. Deploying to a proximity placement group fails

Proximity placement groups pin VMs to specific hardware. If that hardware is full, you can't deploy another VM there. The workaround: create a new proximity placement group in the same region and deploy to that one. You lose the physical proximity, but at least the VM launches.

3. Availability sets cause allocation failures

An availability set groups VMs onto separate fault domains. If you're deploying the 4th VM into a set that has 3 fault domains, Azure may run out of capacity for the 4th in that specific rack. Solution: create a new availability set and deploy the VM there. Then update your application to connect to both sets.

Prevention for next time

You want to avoid hitting this wall again. Here's what I tell my teams:

• Deploy during off-peak hours. If you have a batch of VMs to create, do it at 2 AM local time. The capacity is usually better late at night or early morning.
• Use Azure Reservations. Reserve capacity for a specific VM size in a specific region. Azure guarantees that capacity even during peak times. It costs money upfront but saves headaches.
• Design for multiple regions. If your app can run in three regions instead of one, you won't get stuck when one region fills up.
• Test with two VM sizes from the start. When you write your deployment script or ARM template, include a fallback VM size. If the primary SKU fails, the script tries the secondary.

One last tip: don't keep retrying the same VM size in the same region. I've seen people click deploy 10 times hoping it'll work. It won't. Move to a different size or zone after the first failure. You'll save hours.