Azure VNet Subnet Calculator

When you create a Virtual Network in Azure you have to divide your address space into subnets upfront. Sizing them incorrectly means running out of IPs in one subnet while others sit empty — and Azure does not let you resize a subnet that already contains resources. This calculator uses VLSM to give each subnet exactly the right block size based on your host requirements, then shows you all remaining free space as ready-to-use CIDR blocks.

Enter the IP address block that Azure will assign to your Virtual Network. Every subnet will be carved out of this pool.

1. 1Enter a VNet Base IP — use a private RFC 1918 address such as 10.0.0.0, 172.16.0.0, or 192.168.0.0.
2. 2Drag the CIDR slider or type a Subnet Mask. Azure VNets support /8 to /29. A /16 is the standard starting point for production environments — it gives 65,536 addresses to divide.

Type how many subnets you need into the No. of Subnets box and click Generate Rows. One blank row appears for each subnet — fill in the four fields for each one:

1. →Subnet Name — a label you will recognise in the Azure portal, for example GatewaySubnet, web-public-eastus, or db-service-westeu. Azure requires the dedicated gateway subnet to be named exactly GatewaySubnet.
2. →Region / Zone — type the Azure region or availability zone this subnet belongs to, for example eastus, westeurope, or eastus-az1. This field is free-text and accepts any naming convention.
3. →Type — type gateway, public, private, or service. Gateway subnets host VPN or ExpressRoute gateways. Public subnets hold internet-facing resources such as Application Gateways. Private subnets host VMs and app services. Service subnets are dedicated to Azure PaaS services like Azure Kubernetes Service node pools or SQL Managed Instance.
4. →Hosts Needed — how many resources you expect in this subnet. Size generously since Azure does not allow you to shrink or move a subnet that contains resources. The calculator rounds up to the nearest power-of-2 block and subtracts the 5 Azure-reserved addresses automatically.

Click Generate Plan. Subnets are allocated from largest to smallest (VLSM order) to minimise gaps and boundary-alignment waste. The results table shows your complete IP layout. Here is what each column means:

1. →Subnet Name / Type — your label and a colour-coded type badge (blue = Gateway, green = Public, amber = Private, red = Service).
2. →Region / Zone — the region or zone you entered.
3. →Network (CIDR) — the exact address prefix to enter in the Azure portal when creating this subnet.
4. →Total IPs — the full block size including Azure-reserved addresses.
5. →Azure Reserved — always 5. Shown separately so you can see exactly what Azure takes from every subnet.
6. →Usable IPs — addresses available to assign to resources. This is Total IPs minus 5.
7. →Netmask — the subnet mask in dotted-decimal format for reference.

Key rules from the Azure Well-Architected Framework and Azure networking documentation when sizing subnets:

1. 1Size up, not down. Azure does not allow you to resize a subnet that contains resources. Allocate more space than you need today — unused addresses cost nothing but running out of IPs in a live subnet is a serious incident.
2. 2GatewaySubnet must be named exactly. Azure requires the subnet hosting a VPN or ExpressRoute gateway to be named GatewaySubnet. A /27 (27 usable) is the minimum recommended size; use /26 if you plan to deploy both VPN and ExpressRoute gateways.
3. 3AzureFirewallSubnet needs a /26. If you are deploying Azure Firewall, its dedicated subnet must be named AzureFirewallSubnet and be at least a /26 (59 usable IPs).
4. 4AKS node pools need large subnets. Each AKS node can consume many IPs in CNI mode — plan for the maximum node count multiplied by the max pods per node. A /22 or larger is common for production AKS node pool subnets.
5. 5Reserve space for growth. Leave at least 25–30% of your VNet address space unallocated. Unlike AWS, Azure allows you to add additional address ranges to an existing VNet, but careful upfront planning is still far easier than emergency expansion.

Azure reserves the first four and the last IP address in every subnet. The first is the network address, the second is the default gateway (.1), the third and fourth are mapped to Azure DNS (.2 and .3), and the last is the broadcast address. These five cannot be assigned to any resource. A /29 with 8 total addresses only gives you 3 usable IPs — plan accordingly and avoid very small subnets where the 5-address overhead is significant.

Use a private RFC 1918 range — 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16. For most production VNets, starting with a /16 from the 10.x space gives 65,536 addresses and room to grow. If you plan to connect this VNet to other VNets via peering or to on-premises networks via VPN or ExpressRoute, ensure the ranges do not overlap — peered VNets cannot have overlapping address spaces.

Gateway subnets host Azure VPN Gateways or ExpressRoute Gateways and must be named GatewaySubnet. Public subnets hold internet-facing services such as Azure Application Gateway or Azure Load Balancer with a public IP. Private subnets host virtual machines, App Services, and other workloads that only need outbound internet access through a NAT Gateway or firewall. Service subnets are delegated to specific Azure PaaS services — AKS node pools, Azure SQL Managed Instance, Azure Firewall — each with their own sizing and naming requirements from Microsoft.

You can only resize a subnet if it contains no resources. Once a VM, NIC, or service endpoint is deployed into a subnet, Azure will not allow you to change its address range. Deleting and recreating a subnet requires first removing all resources inside it. This is the most common and most painful Azure networking mistake — always plan your subnet sizes generously before deploying anything into them.

The calculator sorts your subnets from largest required block to smallest before allocating addresses. This is the correct VLSM approach — placing the largest subnets first minimises boundary-alignment waste and ensures all subnets fit within the VNet address space without gaps. Your subnets are then re-sorted by network address for display, so the results table shows them in the natural sequential order they occupy in memory.

After all your subnets are placed, the remaining address space inside your VNet CIDR is decomposed into boundary-aligned CIDR blocks and shown in the free table. These are real, usable address ranges — not gaps or wasted space. You can assign any of these blocks to a new subnet at any time without disrupting existing subnets. The blocks are listed in sequential address order, smallest first, so the first entry is the one immediately after your last allocated subnet.

The smallest subnet Azure supports is a /29, which has 8 total IP addresses. After the 5 Azure-reserved addresses, only 3 usable IPs remain. This is only suitable for very constrained infrastructure subnets — for example, a point-to-site VPN subnet or a small Private Endpoint subnet. Do not use /29 for any subnet that might need to scale. For most workloads, /27 (27 usable) is the practical minimum.