Plan Azure Virtual Network address spaces and subnet allocation with Azure-specific rules.
Last verified: April 2026
Output will appear here...You're designing a hub-and-spoke architecture across 3 Azure regions for a financial services company. Each region needs a hub VNet with Azure Firewall, VPN Gateway, and Bastion, plus 4 spoke VNets for different application tiers. Using the planner, you allocate 10.0.0.0/16 for the primary hub, carve out the mandatory service subnets first (/26 for Firewall, /27 for Gateway, /26 for Bastion), then allocate the remaining space across spoke VNets. The planner catches that your initial allocation leaves no room for a future AKS subnet in spoke-3 and suggests widening the spoke from /22 to /20.
The Azure VNet CIDR Planner helps you design Virtual Network address spaces and subnet allocations following Azure-specific networking rules. It accounts for Azure's reserved IP addresses per subnet, GatewaySubnet requirements, AzureBastionSubnet minimum sizing, and service delegation constraints. The tool visualizes address space utilization and identifies conflicts across VNets.
The planner takes a parent VNet address space and divides it into subnets using alignment-aware allocation. It validates that each subnet falls within the VNet address range, checks for overlaps between proposed subnets, accounts for Azure's 5 reserved IPs per subnet, and enforces minimum size requirements for special-purpose subnets (GatewaySubnet, AzureBastionSubnet, etc.). The output shows the full allocation map with usable IP counts and remaining free space.
Pre-allocate dedicated subnets for Azure services with fixed sizing requirements BEFORE planning general-purpose subnets. GatewaySubnet needs /27, AzureBastionSubnet needs /26, AzureFirewallSubnet needs /26, and Application Gateway needs /24 minimum. These eat into your address space fast and can't be resized without recreation.
When planning for AKS with Azure CNI networking, each pod gets a real VNet IP. Size your AKS subnets for (max_pods_per_node x max_nodes) + service_IPs. A 50-node cluster with 30 pods/node needs 1,500+ IPs — that's a /21 minimum. Teams that allocate a /24 run out of IPs when they try to scale past 8 nodes.
In hub-and-spoke topologies, all spokes must have non-overlapping address spaces with each other AND the hub. Plan your CIDR allocation across the entire organization upfront using a consistent scheme like 10.{region}.{spoke}.0/24. Retroactively re-addressing a peered VNet requires tearing down the peering, migrating resources, and re-establishing connectivity.
Was this tool helpful?
Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.