How to plan for Azure quotas and limits

last updated: April 6, 2020

There are a couple of those limits and quotas you have to take into account when designing an application on Azure. In this post I want to walk you through the most common limits and how to design for them:

• ARM limits: There a couple limits on the actual ARM API level. These apply to your subscription and your resource groups.
• Quota limits: Each service in Azure has the concept of a quota. This means there is a cap on how much resources of a certain type you can deploy. Some of these quotas are hard limits, some are soft limits.
• VM limits: Each specific VM has a limit on the amount of disks, and a cap on storage/network throughput.
• Storage limits: Storage accounts have a cap on their throughput, and each disk has a limit on it\’s throughput as well.
• Network limits: Each VM has specific throughput limits, and there are a couple of other network related limits to take into account.

There is a fantastic page on the Azure documentation that contains most of the service limits. It has most of the services in there, and which soft/hard limits apply to that service. For the most up to date reference, please refer to that page or the links in the Azure documentation provided in the specific sections in this blog post.

ARM Limits

Full list of limits.

Let\’s start with the ARM limits. These are the limits on how many resource groups you can have, how many resources can be in a single resource group, and some limits on ARM templates. Below I highlight some of the most important limits.

Resource	Limit
Resource groups per subscription	980
Tags per resource/resource group/subscription	50
Deployments per subscription/resource group (history)	800
Resources per type per resource group, except for these.	800
Parameters / Variables in a single ARM template	256
Sources per template deployment (includes loops)	800

All of these limits are hard limits.

An important exception is the exception to the \’resources per type per subscription\’ limit. There a number of resources to which this 800 limit does not apply. The good thing is, that VMs, disks and NICS are resources that are exceptions, meaning you could deploy more than 800 VMs in a resource group.

How to plan for these limits

These ARM limits are hard limits (at least for now). It\’s critical that you take them in account when you design your governance structure. A design that is based on creating a single resource for each project/VM can hit the 980 resource group limit. My personal guidance here:

1. Design your governance structure with these limits in mind.
2. If using frequent template deployments, periodically clean up the deployment history.
3. If using automated tagging using Azure Policy, make sure a single resource doesn\’t inherit more than 50 tags.

Quota limits

The next limit you have is the quota you have assigned to your subscription. Quotas are soft limits linked to certain services, most commonly vCPUs in a region, but this could also be the amount of public IP addresses or other services.

To see the current quota assigned to your subscriptions, you have to open the subscription blade in the Azure portal, select your subscription, and select the \’Usage + quotas\’ blade. You can then select the resource providers and locations for which you want to check your quotas.

Important side-note when it comes to quotas related to vCPUs: it does not matter whether a VM is running or not for it to count towards your total quota. Even a stopped and deallocated VM counts towards your total core quota.

You can also query these quota\’s using Azure PowerShell or Azure CLI. In these tools, you need provide it with the location you want to query. For example in Azure CLI:

az vm list-usage -l westus2

To lift quota\’s, you need to open a support case with Microsoft. These support cases are free of charge. These cases can (for now) only be created in the Azure portal. There\’s no cost related to getting a higher quota.

How to plan for these limits

These quota limits can – in most cases – be lifted. Make sure you keep track of them, and you periodically review your limits. If you feel up to it, you can even think about automating the process and create a ticket in Jira/ServiceNow to open a support case with Microsoft to lift certain limits.

1. Periodically review your quota limits.
2. Script the review of quotas and trigger alerts when you hit certain limits/thresholds.
3. Consider a fallback plan to either another SKU or another region in case you hit limits and approval takes some time.

Virtual machine limits and throttles

Full list of VM sizes and throttles.

A lot of deployments to Azure are still VM based. Each VM has a couple of limits and throttles applied to it. The most visible limits are the amount of CPU/memory a VM has, and there are also limits that apply to storage and network performance. Each VM series now has a dedicated page on the documentation, that will contain a table similar to to following which contains all the details.

Let\’s investigate these limits one by one.

CPU

When it comes to CPU, the most visible limit is the amount vCPUs a VM has. For example, a D2s_v3 has 2 vCPUs. Important to note as well, is that for the Dv3/Dsv3 series those vCPUs are hyperthreaded. Hyperthreading means that 2 vCPUs are pinned to 1 physical core. The documentation on VM sizes will show per VM family whether or not the vCPUs in that VM are hyperthreaded or not.

Another CPU benchmark that is relevant to understand is the concept of ACU or Azure Compute Unit. An ACU is a synthetic measure to allow you to compare the compute performance between different Azure SKUs. The ACU is a measure per core. For example, an A-series VM has 100 ACU per core, a Dv3/Dsv3 VM has 160 to 190 ACU per core (depending on Intel Turbo technology).

Storage

When it comes to storage, there are a number of limits to be aware at the VM level:

• Size of the temporary drive.
• Maximum amount of data drives that can be attached
• Maximum amount of cached disk throughput
• Maximum amount of uncached disk throughput.

Let\’s start with the first limit, the size of the temporary drive. The temporary drive – or the ephemeral drive – is a disk that is local to the physical server that your VM is hosted on. This disk gives you good performance (because of locality) but the data is not persisted. The size of the temporary drive depends on the specific size of your virtual machine. An interesting side-remark about this: in VMs that support premium storage (e.g. Ds_v3), the temporary drive is smaller than on machines that do not support premium storage (e.g. D_v3).

If you need persistent data, you\’ll need to attach data disks to a VM. Each VM size has a limited amount of data disks that can be attached. For instance, the D2_v3 can have a maximum of 4 data disks. It doesn\’t matter if these are standard/premium, each data disk will count for 1 disk.

Next limit is the amount of throughput, both in terms of IOPS and MB/s.