Subnet Calculator for AWS VPC

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