Microsoft Azure Subnet Sizing Reference
CIDR Tables and Practical Sizing for Gateways, Firewalls, Bastion, AKS and Private Endpoints
Important Azure rule about usable IPs
In every Azure subnet, Azure reserves 5 IP addresses:
The first 4 addresses and the last address in the subnet are reserved.
Usable IPs in Azure subnet = Total IPs − 5
1. IPv4 CIDR Quick Reference Table
This Table is the Core “Lookup” Engineers need.
|
CIDR |
Total IPs |
Usable IPs in Azure (Total − 5) |
Typical Use |
|
/29 |
8 |
3 |
Very small point use, not recommended for most Azure services |
|
/28 |
16 |
11 |
Small management subnet, a few private endpoints |
|
/27 |
32 |
27 |
Small workload subnet, low node count |
|
/26 |
64 |
59 |
Small to medium workload subnet |
|
/25 |
128 |
123 |
Medium workload subnet |
|
/24 |
256 |
251 |
Standard workload subnet, common default |
|
/23 |
512 |
507 |
Larger workload subnet, larger node pools |
|
/22 |
1024 |
1019 |
High scale subnet, multiple services |
|
/21 |
2048 |
2043 |
Large-scale platform subnet |
|
/20 |
4096 |
4091 |
Enterprise shared services or AKS large pools |
|
/19 |
8192 |
8187 |
Large enterprise segmentation |
|
/18 |
16384 |
16379 |
Very large segmentation blocks |
|
/17 |
32768 |
32763 |
Very large segmentation blocks |
|
/16 |
65536 |
65531 |
VNet-level sizing block, multi-subnet planning |
2. Subnet Sizing Guidelines by Azure Service
This Table gives Practical Defaults and Avoids Common Deployment Failures.
|
Azure Service / Subnet Type |
Recommended Minimum |
Better Practice |
Why it Matters |
|
Application Gateway subnet |
/27 |
/26 or /24 |
App Gateway scales instances and needs room; undersized subnets cause scaling limitations |
|
Azure Firewall subnet (AzureFirewallSubnet) |
/26 |
/24 |
Firewall can scale and uses multiple IPs; /26 is minimum guidance in many designs |
|
Azure Bastion subnet (AzureBastionSubnet) |
/27 |
/26 |
Bastion scaling and feature growth require space |
|
VPN Gateway subnet (GatewaySubnet) |
/27 |
/26 |
Gateway SKU and future scale require address space |
|
ExpressRoute Gateway subnet (GatewaySubnet) |
/27 |
/26 |
Similar gateway scaling considerations |
|
Private Endpoint subnet |
/28 |
/27 or /26 |
Private endpoints accumulate quickly in enterprise environments |
|
Shared services subnet (DNS, jump hosts, mgmt tools) |
/26 |
/24 |
Shared services tend to grow over time |
|
AKS node pool subnet (Azure CNI) |
/24 per node pool |
/23 or /22 for growth |
Node count drives IP usage; running out of IPs is a common AKS issue |
NOTES FOR STRICT DEPLOYMENTS
Some services have explicit subnet naming requirements (GatewaySubnet, AzureFirewallSubnet, AzureBastionSubnet). Always follow those.
3. AKS Subnet and CIDR Planning Tables
AKS planning depends heavily on whether you use Azure CNI (classic), Azure CNI powered by Cilium, or kubenet. The most common enterprise approach is Azure CNI because pods receive routable VNet IPs, but it consumes many IPs.
AKS Critical CIDRs you Must Plan
|
CIDR Type |
What it is |
Must not Overlap with |
Typical Size |
|
Node subnet CIDR |
Subnet where AKS nodes live |
VNets, on-prem, peered VNets |
/24 to /22 per node pool depending on scale |
|
Service CIDR |
Kubernetes virtual IP range for ClusterIP services |
Anything routable in your network |
Often /16 or /20 depending on service count |
|
DNS service IP |
Single IP inside Service CIDR |
Must be within Service CIDR |
1 IP inside Service CIDR |
|
Pod CIDR (kubenet only) |
Pod network range (not VNet IPs) |
Anything routable in your network |
Often /16 or /20 |
AKS Sizing Guidance Table (Practical)
|
Cluster Size Goal |
Node Subnet Suggestion |
Service CIDR Suggestion |
Notes |
|
Small (dev/test) |
/24 |
/24 to /22 |
Keep simple, but avoid future overlap issues |
|
Medium |
/23 |
/20 |
Good baseline for most production clusters |
|
Large |
/22 |
/16 |
Common enterprise sizes, supports growth |
|
Very large |
/21 or larger |
/16 |
Requires governance and careful segmentation |
Important AKS Warning
Most AKS “IP exhaustion” outages are caused by undersizing node subnets. If you do Azure CNI, treat node subnet sizing as a primary design decision, not an afterthought.
4. VNet and Subnet Design Patterns
A Practical Enterprise vNet Pattern (Example)
|
Subnet Category |
Typical CIDR |
Example Purpose |
|
GatewaySubnet |
/26 |
VPN or ExpressRoute gateway |
|
AzureFirewallSubnet |
/24 |
Azure Firewall |
|
AzureBastionSubnet |
/26 |
Bastion |
|
Shared-Services |
/24 |
DNS forwarders, mgmt VMs, monitoring |
|
Workloads-App |
/23 |
App tier |
|
Workloads-Data |
/23 |
Data tier |
|
PrivateEndpoints |
/26 |
Central private endpoint subnet |
|
AKS-NodePool-1 |
/22 |
AKS node pool |
|
AKS-NodePool-2 |
/23 |
AKS node pool expansion |
This is easy to Operate and Scales without Constant Subnet Redesign.
5. Quick Subnet Math Rules
|
Rule |
Meaning |
|
Each subnet loses 5 IPs in Azure |
Total IPs minus 5 = usable |
|
Don’t design to 90–100% usage |
Leave headroom for scale, upgrades, replacements |
|
Plan subnets by growth, not by today |
Subnet resizing later can be disruptive |
|
Keep private endpoints separate |
PE growth is unpredictable in enterprises |
|
Reserve large blocks for AKS early |
AKS scaling demands large contiguous ranges |
For readers who want a complete, Production-Ready CIDR Design Standard covering all major Azure Services, including Real-World Subnet Sizing and Enterprise Best Practices, and to avoid common Design Mistakes that lead to IP Exhaustion, Scaling failures, and costly Network Redesign, see Azure CIDR Architecture Standard for Enterprise Production Environments in the Books section.
0 comments