Plan Subnets for AWS, Azure and Kubernetes

Plan Subnets for AWS, Azure and Kubernetes

Cloud subnets break two habits from on-premises networks. AWS and Azure both reserve 5 addresses in every subnet instead of 2, so a /24 gives you 251 usable hosts, and Kubernetes adds two more address ranges on top of the network the nodes live in. Neither change is hard, but both are expensive to fix later: an undersized subnet usually has to be recreated with its workloads moved out, and a pod or service range that overlaps a network the cluster must reach causes routing failures that are hard to trace.

The three sections below cover the platform rules one at a time. The AWS section works through the reservation math, a three-tier layout across availability zones and the address cost of EKS pods. The Azure section covers the same reservation pattern, the fixed minimum sizes for GatewaySubnet, AzureFirewallSubnet and Application Gateway, and hub-spoke peering. The Kubernetes section explains how node, pod and service CIDRs relate and how to size the pod range for your node count. Run each block through the subnet calculator as you plan, and keep the whole allocation in one list so no two ranges overlap.

Subnet Calculator for AWS VPC

AWS reserves 5 addresses in every subnet, far more than standard IPv4. This changes your host count math.¹

AWS reserves the network address (.0), VPC router (.1), DNS (.2), future use (.3), and broadcast (.255 equivalent) in every subnet. A /24 therefore provides 251 usable addresses instead of 254. For EKS clusters, each pod gets its own IP from the subnet pool via VPC CNI, which means Kubernetes nodes consume addresses rapidly. Planning VPC CIDR blocks before deploying workloads prevents address exhaustion that requires destructive VPC recreation.

AWS subnet address reservation math

Inside any AWS subnet, five addresses are unavailable: .0 (network), .1 (VPC router), .2 (Route 53 DNS resolver), .3 (future use), and the last address (broadcast equivalent). A /24 starts with 256 total addresses; subtract 5 to get 251 usable. A /27 starts with 32 total; subtract 5 to get 27 usable. Consequently, for small subnets, AWS reservations consume a meaningful percentage: a /28 (16 total) loses 5 reservations, leaving only 11 usable. Building on this, specialty subnets like GatewaySubnet, NAT Gateway subnets, and Lambda ENI subnets need /27 or /26 instead of the /29 or /28 you might choose in a non-cloud environment.

Multi-AZ subnet layout

A standard three-tier VPC across 3 AZs uses 9 subnets minimum: one public, one private, and one data subnet per AZ.² Allocating /24 per subnet from a /16 VPC CIDR leaves 247 /24 blocks unused, giving you room for growth, additional services, and future AZ expansion. Building on this, naming and numbering the subnets by AZ makes routing table maintenance easier: public subnets at 10.0.0.0/24, 10.0.1.0/24, 10.0.2.0/24 across AZs; private subnets at 10.0.10.0/24, 10.0.11.0/24, 10.0.12.0/24; data subnets at 10.0.20.0/24, 10.0.21.0/24, 10.0.22.0/24. Consequently, the first octet of the third byte encodes the tier, making the topology readable at a glance in the console.

EKS and Lambda VPC CIDR planning

EKS with VPC CNI assigns one VPC IP per pod, depleting address space rapidly on busy nodes.³ With the default pod limit of 110 per node and 10 nodes, 1,100 pod IPs plus 10 node IPs require a minimum /21 per node subnet (2,046 usable, 2,041 after AWS reservations).

VPC CNI prefix delegation

Building on this, enabling VPC CNI prefix delegation multiplies pod capacity by 16: each node ENI gets a /28 prefix instead of individual IPs, so a /22 node subnet (1,019 usable) supports far more pods per node. Lambda functions in a VPC create ENIs from the subnet pool during concurrency scaling, so a /24 (251 usable) is the minimum recommended subnet size to prevent ENI exhaustion during traffic spikes.

Plan the node subnet larger than today's pod count to absorb burst workloads. A cluster that runs 200 pods now can triple during a deploy or a traffic surge, and a /24 leaves little margin for that. CapyToolkit shows the usable count after AWS reservations so you can pick a prefix that covers peak demand before provisioning the node group.

VPC IP Address Manager (IPAM) for multi-account planning

AWS VPC IP Address Manager (IPAM) provides centralized CIDR tracking across multiple AWS accounts and regions, preventing the overlapping allocations that break VPC peering and Transit Gateway routing. IPAM operates as a regional service with a top-level pool (for example, 10.0.0.0/8) that you subdivide into regional pools, then into account-level allocations. When a new VPC is provisioned through IPAM, the service automatically assigns the next available CIDR from the appropriate pool.

Building on this, IPAM monitors utilization per subnet and alerts when address utilization crosses a threshold you define. For organizations managing hundreds of VPCs across dev, staging, and production accounts, IPAM eliminates the spreadsheet-based IP tracking that inevitably drifts out of date. Consequently, integrating IPAM into your account vending machine or landing zone automation ensures every new VPC receives a non-overlapping CIDR without manual coordination between teams.

IPAM and IPv6 pool management

IPAM also manages IPv6 pools, tracking /48 and /56 allocations from your BYOIP (Bring Your Own IP) block or from Amazon-provided IPv6 CIDRs.⁴ The same allocation logic applies: define the top-level IPv6 pool, create regional child pools, and let IPAM assign /56 or /48 blocks to individual VPCs. Planning both IPv4 and IPv6 pools in IPAM from the start prevents the situation where a VPC is provisioned with IPv4 but has no IPv6 block available, requiring a secondary CIDR addition that disrupts existing route tables.

Transit Gateway and cross-VPC subnet routing

AWS Transit Gateway connects thousands of VPCs and on-premises networks through a single routing hub. Each VPC attachment to a Transit Gateway requires a subnet from each VPC to host the attachment ENI. These attachment subnets must not overlap with any other VPC or on-premises network connected to the same Transit Gateway, or routing black holes occur.

When planning Transit Gateway connectivity, reserve a small subnet (/28 or /27) in each VPC specifically for the TGW attachment.⁵ Building on this, the Transit Gateway route table determines which VPCs can communicate: a spoke VPC with 10.1.0.0/16 attached to the same TGW as 10.2.0.0/16 can reach both if the TGW route table propagates both prefixes. For inspection architectures, traffic between spokes routes through a security VPC containing third-party firewalls, which requires careful route table design to ensure symmetric flow.

Inspection VPC and symmetric routing

The subnet calculator verifies each VPC's CIDR and the TGW attachment subnet before creating attachments, preventing the costly process of detaching and re-adding VPCs to fix address conflicts. For inspection architectures where traffic between spokes must flow through a security VPC, the calculator confirms that the inspection subnet is large enough for the firewall ENIs and that no CIDR overlaps exist between the inspection VPC and the spoke VPCs it protects.

When to use this

Use the subnet calculator to size an AWS VPC CIDR for EKS pods when creating a new AWS VPC or adding subnets, especially before deploying clusters where address exhaustion is hard to reverse without recreating subnets.

Examples

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

Kubernetes Pod and Node Subnet Planning

Kubernetes assigns three CIDR ranges: one for nodes, one for pods, one for Services. Overlapping any two causes cluster failure.¹

The pod CIDR (clusterCIDR) is divided among nodes by the controller manager; each node receives a /24 block from which the CNI plugin assigns pod IPs. The service CIDR (serviceClusterIPRange) is purely virtual, meaning no packets leave the node using these addresses. Node IPs come from the VPC or on-premises subnet. All three ranges must be non-overlapping, and none should conflict with external networks the cluster must reach, including cloud metadata endpoints and corporate subnets.

Kubernetes CIDR allocation architecture

Inside a Kubernetes cluster, three independent CIDR ranges operate simultaneously. The node CIDR is a real network range: node IPs come from a VPC subnet or on-premises VLAN and appear in routing tables. The pod CIDR is a virtual overlay range; the controller manager slices it into per-node blocks and the CNI plugin assigns individual pod IPs from each node's block. The service CIDR is purely virtual, as Service IPs exist only as iptables or eBPF rules on each node and never appear on the wire. Consequently, the service CIDR only needs to avoid conflicts with real destinations reachable from the cluster, not with subnets behind a VPN or in a corporate network.

Node CIDR vs. pod CIDR vs. service CIDR

The node CIDR is the only one that must align with your VPC or on-premises routing. Pod and service CIDRs are local to the cluster; they never appear in external routing tables. This means you can safely use 10.96.0.0/12 for pods even if your corporate network uses 10.0.0.0/8, because no pod traffic leaves the cluster without NAT or egress gateway translation. Node IPs appear in VPC route tables and must not overlap with any peered VPC or on-premises CIDR. Pod IPs are assigned from the per-node block and only need to be unique within the cluster. Service IPs are purely virtual and only need to avoid overlapping with real destinations the cluster must reach through a VPN or peering connection.

Sizing pod CIDRs for density

Kubernetes assigns one /24 block per node from the cluster pod CIDR by default.² A 100-node cluster consumes 100 /24 blocks from the pod CIDR. A /16 pod CIDR provides 256 /24 blocks, comfortably covering a 100-node cluster with room for 156 additional nodes.³ Building on this, the per-node pod limit defaults to 110 pods per node, so each /24 (256 addresses) has enough capacity for the maximum density plus gateway addresses. For clusters larger than 256 nodes, a /15 or /14 pod CIDR is necessary. Furthermore, the pod CIDR must not overlap with the service CIDR or with any external network; RFC 1918 ranges used in the corporate network make 10.96.0.0/12 a common choice for the pod CIDR when corporate infrastructure uses 10.0.0.0/8.

Calculating node count from pod CIDR size

To determine how many nodes your pod CIDR can support, divide the total addresses by 256 (one /24 per node). A /16 supports 256 nodes, a /15 supports 512, and a /14 supports 1,024. CapyToolkit shows the total address count for any prefix, so you can verify your pod CIDR supports your planned node count before provisioning. This calculation gives you a hard upper bound based on the per-node /24 block size, independent of how many pods each node actually runs.

Leave headroom for cluster growth when you pick the pod CIDR. A team expecting 150 nodes today fits in a /16, but a future expansion to 300 nodes forces a wider prefix that cannot be changed after the cluster is created. CapyToolkit displays the node ceiling for each prefix, so choosing a /15 now costs nothing extra and avoids a painful cluster rebuild later.

Avoiding CIDR conflicts

The most dangerous Kubernetes CIDR conflict is between the pod CIDR and a reachable external network. If pods are assigned IPs from 192.168.0.0/16 and the cluster must reach corporate services at 192.168.10.0/24, pod traffic destined for those services routes locally instead of through the corporate VPN, silently dropping external connectivity. Consequently, always check all corporate and VPN-connected ranges before choosing pod and service CIDRs. Building on this, cloud metadata services at 169.254.169.254 must remain reachable from every node; the pod CIDR must not contain this address, and service CIDRs must not overlap with 169.254.x.x. The standard approach is to use 10.96.0.0/12 for pods and 10.112.0.0/12 for services in environments where corporate infrastructure lives in different 10.x.x.x ranges.

Choosing between 10.96.0.0/12 and 172.16.0.0/12 for pods

Both ranges work well for pod CIDRs because they sit inside the RFC 1918 10.0.0.0/8 or 172.16.0.0/12 blocks but are large enough for most clusters. The 10.96.0.0/12 is the kubeadm default and provides about 4 million addresses. Use 172.16.0.0/12 when your corporate network already occupies the 10.0.0.0/8 space and you need a pod CIDR that will not conflict. The key constraint is that the pod CIDR must not overlap with any network the cluster needs to reach through a VPN or peering connection.

EKS IP address management with VPC CNI prefix delegation

AWS VPC CNI prefix delegation assigns a /28 prefix (16 IPs) to each node ENI instead of individual IPs, dramatically increasing pod density per node.⁴ Without prefix delegation, a c5.large node (3 ENIs, 10 secondary IPs per ENI) supports 30 pods maximum. With prefix delegation, each ENI gets 8 /28 prefixes, giving 128 pod IPs per ENI and 384 pods per node. The tradeoff: each /28 prefix is reserved for one node even if only 2 pods are running, which consumes VPC address space faster.

Building on this, plan your node subnet CIDRs to accommodate the prefix-delegated capacity. A /22 node subnet (1,019 usable after AWS reservations) supports 254 /28 prefixes, enough for 254 nodes at maximum prefix allocation. If your cluster has 50 nodes, a /22 is generous; if it has 200 nodes, you need at least a /21. The subnet calculator shows the exact usable count for any prefix, which you divide by 16 (addresses per /28) to get the prefix count, then compare against your node count. Consequently, prefix delegation changes the subnet sizing formula from "pods per node" to "nodes per subnet," which is a simpler and more predictable planning model.

Calico and Cilium overlay modes: reducing subnet dependency

Calico and Cilium both offer overlay (tunnel) modes that decouple pod IPs from the underlying VPC subnet. In overlay mode, pods receive IPs from a private range (Calico defaults to 192.168.0.0/16; Cilium uses 10.0.0.0/8 by default) that is encapsulated in VXLAN or Geneve tunnels between nodes.⁵⁶ The VPC subnet only needs to accommodate node IPs, not pod IPs, which means a /24 node subnet supports any number of nodes up to 251 regardless of pod count.

Building on this, overlay mode trades some performance (encapsulation overhead of 50 to 100 bytes per packet and additional CPU for tunnel processing) for dramatically simpler IP planning. For clusters where pod-to-pod latency is not critical (batch processing, internal tools), overlay mode eliminates the need for large pod CIDRs entirely. The subnet calculator still applies: size the node subnet for your node count, and size the overlay pod CIDR for your maximum pod count. The difference is that the overlay pod CIDR does not consume VPC address space, so you can use a generous /16 without impacting your cloud IP budget.

When to use this

Use the subnet calculator to verify pod and service CIDRs don't overlap when provisioning a Kubernetes cluster; conflicts produce routing failures that are difficult to diagnose post-deployment.

Examples