Fix Azure 'OperationNotAllowed' Quota Error Fast

Azure VM deployment hits 'OperationNotAllowed' when you're out of vCPU quota. I'll show you the fastest way to check, request more, or just pick a different region.

You're trying to spin up a new VM in Azure, maybe a Standard_D4s_v5 for a dev box or a Standard_F8s_v2 for a batch job, and the deployment just sits there. Then the error lands: OperationNotAllowed. No details beyond that, just a generic code that makes you want to throw your laptop out the window. I've seen this dozens of times, and it's usually the same story: you've hit your subscription's vCPU quota in that region.

The scenario is almost always a fresh subscription or an account that's been live for a while but you've never checked quotas. You might have created a few VMs, or your team has an autoscale group that went nuts overnight. The Azure portal shows the error under 'Deployment details' but the message is frustratingly vague. You'll also see it if you're trying to deploy a VM size that needs a different quota family—like Eadsv5 for memory-intensive workloads—and that family's quota is zero.

Why This Happens

Azure doesn't let you run unlimited VMs. Every subscription has a default vCPU quota per region, and it's split across families. For example, the Dv5 family might have a quota of 10 vCPUs, while Fsv2 has 6. When you try to deploy a VM that would push you past that number, Azure blocks it with OperationNotAllowed. The twist is that the error doesn't tell you which quota you hit—that's the fun part.

The real culprit is almost always the total regional vCPUs quota, not the specific family. You might have room in the family you're using, but if the regional cap is exhausted, you're stuck. I've also seen cases where a subscription has a default quota of 0 for certain VM families (like GPU instances) unless you request it explicitly.

The Fix: Step-by-Step

Here's the process I follow every time this error hits. It's boring, but it works.

Check your current quota in the portal. Go to Subscriptions → your subscription → Quotas. You'll see a list of all quota types per region. Look for the region you're deploying to (e.g., East US, West Europe). Check Total regional vCPUs and the specific family you're using (like Standard Dv5 Family vCPUs). If either shows Current usage close to Limit, that's your problem.
Request a quota increase. In the same Quotas blade, click on the quota you need to bump (usually regional or the specific family). Click Request increase. You'll fill out a simple form—say you need more vCPUs for a production workload, and give a rough estimate of how many. Microsoft typically approves these within a few hours, sometimes faster if you're a pay-as-you-go customer. I've gotten increases in 30 minutes.
Alternatively, just switch regions. If you're not locked into a specific datacenter, try deploying to a neighboring region. For example, if East US is maxed, try East US 2. Azure's quota is per-region, so a different region might have plenty of headroom. I've done this for quick test environments more times than I can count.
If you're in a pinch, resize the VM. If you already have a VM running and you just need more power, you might be able to resize it to a different family that has quota left. Go to your VM → Size → pick a size from a family that's not at its limit. It's not always possible, but it's worth a shot.

Still Failing? Here's What Else to Check

Sometimes OperationNotAllowed isn't about quota at all. If the quota check looks fine, poke around these areas:

Resource group locks. A ReadOnly lock on the resource group will block any VM creation. Go to your resource group → Locks, and remove any locks that shouldn't be there.
Policy restrictions. Azure Policy can deny VM deployments based on tags, location, or size. Check Policy → Compliance for any violations. A policy that restricts allowed VM sizes will throw OperationNotAllowed.
Service limits on managed disks. If you're deploying a new VM with a large managed disk, you might hit the disk quota (e.g., Standard SSD storage limits). Check the quota blade for Managed Disks as well.
Resource provider registration. This is a long shot, but if Microsoft.Compute isn't registered on your subscription, you'll get weird errors. Run this in Cloud Shell: az provider register --namespace Microsoft.Compute

If you've checked all that and still get the error, open a support ticket. Include the deployment ID from the portal, the exact VM size, and the region. But honestly, in 14 years, I've never had a ticket that wasn't resolved by quota or a lock.

One last thing: don't bother deleting old VMs to free up quota unless you're sure they're not needed. Azure's quota is based on total vCPUs allocated, not running ones. Deleting a VM frees it, but you have to actually delete (not just stop) to see the change. Stopping a VM doesn't release the quota—that's a rookie mistake.