Azure Quotas and Limits: What They Are and How to Manage Them

What Quotas Are

A quota is a maximum count or capacity limit for a specific resource type, scoped to a subscription and region. For example, a new Azure subscription in East US typically has a quota of 10-20 vCPU cores for the D-series VM family. If your workload requires 30 D-series VMs with 2 vCPUs each, you need 60 vCPU cores — three to six times the default. Deploying VM #6 or #11 will fail with a quota error until you request an increase.

Quotas are scoped two ways:

• Per region: Your vCPU quota in East US is separate from your quota in West Europe. You can have capacity in one region that you do not have in another.
• Per subscription: Each subscription has its own independent quotas. Creating a second subscription gives you a fresh set of default quotas.

Most quotas are soft limits — Microsoft will increase them if you submit a support request with justification. A smaller number are hard limits that cannot be changed regardless of the reason. The Azure portal’s Quotas page indicates which is which.

Common Limits That New Teams Hit

The following table shows the limits most commonly encountered by teams in their first months on Azure, along with the default value and how to check each one via CLI:

The vCPU quota is by far the most commonly hit limit. New subscriptions often start at 10-20 cores per region, which is enough to test with small VMs but insufficient once a team scales up or runs a load test.

Checking Current Quotas via CLI

VM vCPU Quotas

The az vm list-usage command shows all VM-related quotas for a region, including both the total vCPU limit and per-VM-family sub-limits:

az vm list-usage --location eastus --output table

The output shows three columns: Name, CurrentValue (how many you are currently using), and Limit (your quota). A row where CurrentValue is close to Limit is a quota that will block your next deployment if you scale.

To filter to only the rows where you are using more than 50% of the limit:

az vm list-usage --location eastus \
  --query "[?currentValue > (limit / 2)]" \
  --output table

To see just the total vCPU quota:

az vm list-usage --location eastus \
  --query "[?name.value=='cores']" \
  --output table

Network Quotas

az network list-usages --location eastus --output table

This shows limits for virtual networks, subnets, public IP addresses, network security groups, load balancers, and other networking resources.

Storage Account Count

The 250 storage account limit per subscription is one that microservices teams can hit if each service gets its own storage account:

# Count storage accounts in the subscription
az storage account list --query "length(@)" --output tsv

If you are approaching 250, consolidate storage accounts by using containers and blob prefixes to separate data logically within fewer accounts.

Checking Quotas in the Portal

The portal has a dedicated Quotas page that consolidates quota information across all services in one place:

1. In the Azure portal, search for “Quotas” in the top search bar.
2. Click on the Quotas service. You see a list of resource providers.
3. Click on a provider like Microsoft.Compute to see all compute-related quotas for all regions.
4. Use the Region filter to narrow to a specific region like East US.
5. The table shows the current usage and limit for each quota. A usage bar makes it easy to spot quotas nearing their limit.

The Quotas page also has a Request increase button directly in the interface, making it easy to go from viewing a quota to requesting an increase in one flow.

Requesting a Quota Increase

Most quota increases are requested through an Azure support ticket. You do not need a paid support plan — quota increase requests are free regardless of your support tier.

Via the Portal (Recommended)

The fastest path:

1. Go to the Quotas page in the portal.
2. Find the specific quota you need to increase (e.g., “Standard Dv4 Family vCPUs” in East US).
3. Click Request increase in the row for that quota.
4. Enter the new limit you need. Be realistic — requesting 100 cores when you currently use 2 may require justification.
5. Describe your use case briefly in the details field (e.g., “We are scaling our API fleet to 20 VMs for a production launch on [date]”).
6. Submit the request. You will receive an email update as Microsoft processes it.

Via CLI

You can create a support ticket for a quota increase via CLI, though the portal flow is typically faster:

az support tickets create \
  --ticket-name "vCPU Quota Increase East US" \
  --title "Request vCPU core quota increase for Standard_Dv4 in East US" \
  --description "We need 100 Standard Dv4 vCPU cores in East US for production scaling" \
  --problem-classification "/providers/Microsoft.Support/services/quota_service_guid/problemClassifications/vm_quota_guid" \
  --severity "minimal" \
  --contact-first-name "Your" \
  --contact-last-name "Name" \
  --contact-email "your@email.com" \
  --contact-phone "555-555-5555" \
  --contact-country "USA" \
  --contact-preferred-time-zone "Pacific Standard Time" \
  --contact-preferred-support-language "en-US"

The problem classification GUIDs vary by service type. The portal UI is easier for one-off requests. Use CLI for scripting recurring requests in automated processes.

Real Scenario: Hitting the vCPU Quota During a Load Test

Here is a common sequence of events that happens to teams who do not check quotas in advance:

1. The team has a subscription with a default quota of 10 total vCPUs in East US.
2. They have 3 D2s_v4 VMs running (6 vCPUs), leaving 4 available.
3. A load test is scheduled. The plan is to scale a VM Scale Set from 3 to 15 instances (each is 2 vCPUs = 30 total needed).
4. The Scale Set scale-out operation starts. It successfully creates 2 new VMs (4 vCPUs, reaching the quota), then fails on the third with: Operation could not be completed as it results in exceeding approved Total Regional Cores quota.
5. The scale-out is stuck at 5 VMs instead of 15. The load test cannot proceed. A quota increase request is submitted — and approved 2 hours later. But the load test window has passed.

The fix: check the vCPU quota at the start of any sprint where scaling is planned:

az vm list-usage --location eastus --output table | grep -E "Name|cores|Standard D"

If the limit minus current usage is less than the peak you need, request an increase that week, not the day of the test.