Quotas, virtual machine size restrictions, and region availability in Azure Kubernetes Service (AKS)

All Azure services set default limits and quotas for resources and features, including usage restrictions for certain virtual machine (VM) SKUs.

This article details the default resource limits for Azure Kubernetes Service (AKS) resources and the availability of AKS in Azure regions.

Service quotas and limits

Resource	Limit
Maximum clusters per subscription	5000 Note: spread clusters across different regions to account for Azure API throttling limits
Maximum nodes per cluster with Virtual Machine Scale Sets and Standard Load Balancer SKU	5000 across all node-pools (default limit: 1000) Note: Running more than a 1000 nodes per cluster requires increasing the default node limit quota. Contact support for assistance.
Maximum nodes per node pool (Virtual Machine Scale Sets node pools)	1000
Maximum node pools per cluster	100
Maximum pods per node: with Kubenet networking plug-in	Maximum: 250 Azure CLI default: 110 Azure Resource Manager template default: 110 Azure portal deployment default: 30
Maximum pods per node: with Azure Container Networking Interface	Maximum: 250 Default: 30
Open Service Mesh (OSM) AKS addon	Kubernetes Cluster Version: AKS Supported Versions OSM controllers per cluster: 1 Pods per OSM controller: 1600 Kubernetes service accounts managed by OSM: 160
Maximum load-balanced kubernetes services per cluster with Standard Load Balancer SKU	300
Maximum nodes per cluster with Virtual Machine Availability Sets and Basic Load Balancer SKU	100

Kubernetes Control Plane tier	Limit
Standard tier	Automatically scales Kubernetes API server based on load. Larger control plane component limits and API server/etc instances.
Free tier	Limited resources with inflight requests limit of 50 mutating and 100 read-only calls. Recommended node limit of 10 nodes per cluster. Best for experimenting, learning, and simple testing. Not advised for production/critical workloads.

Provisioned infrastructure

All other network, compute, and storage limitations apply to the provisioned infrastructure. For the relevant limits, see Azure subscription and service limits.

Important

When you upgrade an AKS cluster, extra resources are temporarily consumed. These resources include available IP addresses in a virtual network subnet or virtual machine vCPU quota.

For Windows Server containers, you can perform an upgrade operation to apply the latest node updates. If you don't have the available IP address space or vCPU quota to handle these temporary resources, the cluster upgrade process will fail. For more information on the Windows Server node upgrade process, see Upgrade a node pool in AKS.

Supported VM sizes

The list of supported VM sizes in AKS is evolving with the release of new VM SKUs in Azure. Please follow the AKS release notes to stay informed of new supported SKUs.

Restricted VM sizes

VM sizes with less than two CPUs may not be used with AKS.

Each node in an AKS cluster contains a fixed amount of compute resources such as vCPU and memory. If an AKS node contains insufficient compute resources, pods might fail to run correctly. To ensure the required kube-system pods and your applications can be reliably scheduled, AKS requires nodes use VM sizes with at least two CPUs.

For more information on VM types and their compute resources, see Sizes for virtual machines in Azure.

Supported container image sizes

AKS doesn't set a limit on the container image size. However, it's important to understand that the larger the container image, the higher the memory demand. This could potentially exceed resource limits or the overall available memory of worker nodes. By default, memory for VM size Standard_DS2_v2 for an AKS cluster is set to 7 GiB.

When a container image is very large (1 TiB or more), kubelet might not be able to pull it from your container registry to a node due to lack of disk space.

Region availability

For the latest list of where you can deploy and run clusters, see AKS region availability.

Cluster configuration presets in the Azure portal

When you create a cluster using the Azure portal, you can choose a preset configuration to quickly customize based on your scenario. You can modify any of the preset values at any time.

Preset	Description
Standard	Best if you're not sure what to choose. Works well with most applications.
Dev/Test	Best for experimenting with AKS or deploying a test application.
Cost-optimized	Best for reducing costs on production workloads that can tolerate interruptions.
Batch processing	Best for machine learning, compute-intensive, and graphics-intensive workloads. Suited for applications requiring fast scale-up and scale-out of the cluster.
Hardened access	Best for large enterprises that need full control of security and stability.

Next steps

You can increase certain default limits and quotas. If your resource supports an increase, request the increase through an Azure support request (for Issue type, select Quota).