Subnet Calculator for Azure VNet

Subnet Calculator for Azure VNet

Azure Virtual Networks follow the same reservation pattern as AWS but with gateway and service-specific subnet sizing constraints that affect your address plan.¹

Azure Virtual Networks use address spaces of one or more CIDR blocks. Every subnet must fall within the VNet address space and cannot overlap with other subnets. The GatewaySubnet requires a /27 or larger for VPN and ExpressRoute gateways. Application Gateway v2 requires a dedicated /24 subnet. Azure Kubernetes Service needs either a /24 per node pool in kubenet mode or a larger block in Azure CNI mode where each pod gets a VNet IP.

Azure subnet reservation math

Inside every Azure subnet, 5 addresses are reserved: .0 (network), .1 (default gateway), .2 and .3 (Azure DNS mapping), and the last address (broadcast equivalent). A /24 provides 251 usable addresses; a /27 provides 27; a /28 provides 11. Understanding how these reservations scale down is critical; small subnets lose a disproportionate percentage of their address space to Azure's fixed five-address overhead.

Gateway and service-specific subnet sizing

Consequently, speciality subnets like GatewaySubnet require /27 or larger; Microsoft recommends /27 for basic VPN and /26 for zone-redundant or ExpressRoute gateway deployments. Building on this, Application Gateway v2 requires a dedicated subnet of at least /24 because the service autoscales by allocating additional IPs, and a smaller subnet exhausts rapidly under load. Planning these specialty subnets first before allocating workload blocks ensures the constrained-size subnets get the boundaries they need.

Account for Azure's five reserved addresses in every specialty subnet, not just the workload blocks. A GatewaySubnet /27 loses 5 of its 32 addresses, leaving 27 for gateway use, so the headroom is thinner than the prefix suggests. CapyToolkit subtracts the reservations automatically, so the usable count you see already reflects the real address space available to the service.

Hub-spoke VNet topology

Azure hub-spoke topology connects a central hub VNet (containing the gateway, firewall, and management services) to multiple spoke VNets (containing workloads) via VNet peering.² The hub VNet receives a /22 or /23 CIDR to accommodate the gateway /27, firewall /26, and management /28 subnets. Each spoke VNet gets its own non-overlapping CIDR from a different part of the address space: spoke 1 at 10.1.0.0/20, spoke 2 at 10.2.0.0/20. Building on this, VNet peering requires non-overlapping address spaces: two VNets with the same CIDR cannot be peered. Consequently, maintaining an allocation spreadsheet or IPAM system before provisioning any VNet prevents peering conflicts that require VNet recreation to resolve.

AKS and Application Gateway subnet sizing

AKS with kubenet assigns pod IPs from a separate overlay network, so pods do not consume VNet IPs directly and a /24 node subnet accommodates many nodes and their system pods. AKS with Azure CNI assigns one VNet IP per pod, consuming address space fast.³ For 10 nodes with 100 pods each, 1,010 IPs minimum require a /22 (1,019 usable after Azure reservations). Building on this, the Application Gateway v2 subnet must be /24 or larger and dedicated; no other resources share it.⁴ Furthermore, Azure Bastion requires a subnet named exactly AzureBastionSubnet at /26 minimum. Planning all specialty subnets first, then allocating workload subnets from the remaining space, avoids having to resize or recreate subnets later.

Azure Firewall and subnet requirements

Azure Firewall requires a dedicated subnet named exactly AzureFirewallSubnet with a minimum size of /26.⁵ This subnet hosts the firewall's managed infrastructure and must not contain any other resources. When you deploy Azure Firewall, the service allocates multiple IP addresses from this /26 block for scaling and high availability. Consequently, a /25 or /24 is the practical choice for production deployments to ensure enough addresses are available during scale events.

Azure Firewall Manager policies apply to the firewall instance on this subnet, controlling network rules, application rules, and threat intelligence settings. Building on this, forced tunneling routes all internet-bound traffic through the Azure Firewall by setting 0.0.0.0/0 to the firewall's private IP via a user-defined route (UDR) on each workload subnet. The AzureFirewallSubnet itself does not need a UDR because the firewall handles its own egress directly. Planning the AzureFirewallSubnet CIDR before deploying any workload subnets ensures the firewall block does not fragment your VNet address space.

Hub VNet with Azure Firewall in a hub-spoke topology

In a hub-spoke deployment, the hub VNet contains the Azure Firewall, VPN gateway, and ExpressRoute gateway. The AzureFirewallSubnet (/26), GatewaySubnet (/27 or larger), and management subnets all live in the hub. Spoke VNets peer with the hub and route 0.0.0.0/0 to the firewall's private IP. Building on this, each spoke VNet's address space must not overlap with the hub or with other spokes.⁵ Using the subnet calculator to pre-allocate non-overlapping CIDRs for every spoke before creating VNet peerings prevents the costly process of deleting and recreating peered VNets to fix address conflicts.

Private Endpoints and subnet delegation in Azure

Azure Private Endpoints assign a VNet IP to a PaaS service (like Azure Storage or Azure SQL), making it accessible as though it were on your local network. Each Private Endpoint consumes one IP from the subnet where it is deployed. For environments with many Private Endpoints, delegate a dedicated subnet (for example, /27 or /24) to Microsoft.Sql or the appropriate service delegation. This keeps Private Endpoint IPs separate from workload subnets and simplifies NSG and UDR management.

Subnet delegation assigns a subnet to a specific Azure service that injects its infrastructure directly into your VNet. Azure Firewall uses AzureFirewallSubnet; Azure NetApp Files uses Microsoft.NetApp/volumes; Azure Spring Apps uses Microsoft.App/Spring. Building on this, a delegated subnet cannot host other resource types, so plan delegation subnets as part of the initial address space design.

Pre-planning delegation CIDRs

The subnet calculator helps you carve the correct-sized blocks for each delegation before running the subnet create command with the delegation flag. Consequently, pre-planning delegation CIDRs prevents the situation where a service deployment fails because no correctly-sized subnet exists for it. By listing every delegated subnet your deployment requires upfront, you can sum their sizes and verify they fit within the VNet address space alongside the GatewaySubnet, AzureFirewallSubnet, and workload blocks.

When to use this

Use the subnet calculator to lay out an Azure VNet CIDR without overlapping spokes when planning a VNet, sizing subnets for AKS node pools, or validating hub-and-spoke CIDRs before enabling peering.

Examples