VPC subnet calculator: split a CIDR block and plan IP exhaustion

How it is calculated

mask      = 2^32 − 2^(32−p)
network   = address AND mask
broadcast = network OR NOT mask
size      = 2^(32−p)

usable = size − reserved
reserved: AWS 5, Azure 5, Google Cloud 4, generic 2
(generic: a /31 has 2 usable, a /32 has 1)

AWS VPC CNI             1 + P + w
AWS VPC CNI prefix      1 + 16 × (ceil(P ÷ 16) + 1)
Azure CNI               1 + P
Overlay, Azure Overlay  1
GKE alias IP            1, plus one /24 pod range per node (returned separately)

r = ceil((tier demand + Kubernetes demand) × growth_factor)
prefix = the longest p whose usable count is at least r,
         kept inside the cloud's subnet range (AWS /28 to /16)

Sort subnets by size, largest first (ties: tier order, then zone).
Place each at the lowest free address that is a multiple of its size.
Ranges in overlap_with are removed from free space first.
Free space is returned as the fewest aligned CIDR blocks.

utilization  = demand ÷ usable
projected    = ceil(demand × growth_factor) ÷ usable
a and b overlap when a.network ≤ b.broadcast and b.network ≤ a.broadcast
newbits = p − p_base
netnum  = (network − network_base) ÷ 2^(32−p)
cidrsubnet(base, newbits, netnum)

Assumptions

• Everything is IPv4 bit arithmetic on the numbers you enter. Nothing is looked up and nothing leaves the page.
• Subnets are sized for the projected demand (demand × growth_factor); the table also shows today's demand, utilization and headroom.
• SUBNET_NEAR_EXHAUSTION compares projected demand with usable addresses (80% or more); AWS_SUBNET_NOT_RESIZABLE fires above 90%.
• A tier with a fixed prefix (spoke-a:custom:/20) keeps that prefix; if Kubernetes demand needs a larger block, the larger block wins.
• Kubernetes rows are planning formulas from the CNI documentation: the node's own address, its pods and the warm addresses. Extra network interfaces' own addresses and upgrade surge nodes are not counted unless you add them to the node count.
• GKE pod ranges use the default of one /24 per node, which supports up to 110 pods per node.
• IPv6 follows AWS rules: a /56 per VPC and a /64 per subnet, so a VPC holds 256 subnets.
• The reserved-address and subnet-size rules were read from each provider's documentation on 2026-11-05 and are reviewed yearly.

The data behind it

Three ways to reduce this number

1. Enable prefix delegation or use an overlay CNI so pods stop consuming subnet addresses.
2. Add a secondary CIDR such as 100.64.0.0/10 for pods (AWS accepts blocks from it) instead of growing the main range.
3. Leave aligned free space instead of packing the base block full, so a subnet can be added later without renumbering.

Use it from code

The same engine is available as a REST endpoint and as an MCP tool named calc_cidr_vpc_subnet_planner. Your scenario as an API call:

curl -X POST 'https://api.x12i.com/v1/calc/cidr-vpc-subnet-planner' \
  -H 'Authorization: Bearer YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{
  "input": {
    "mode": "plan",
    "base_cidr": "10.0.0.0/16",
    "cloud": "aws",
    "az_count": 3,
    "ipv6": false,
    "tiers": [
      "app:private:4000",
      "data:private:500",
      "public:public:50"
    ],
    "growth_factor": 2,
    "k8s_cni": "none",
    "k8s_nodes_per_az": 10,
    "k8s_pods_per_node": 30,
    "k8s_warm_ips_per_node": 5,
    "overlap_with": [],
    "split_count": 4,
    "cidrs": [
      "10.0.0.0/16",
      "10.0.1.0/24",
      "192.168.0.0/16"
    ]
  },
  "options": {
    "explain": false
  }
}'

Copy as API call Schema: GET /v1/calc/cidr-vpc-subnet-planner/schema

Frequently asked questions

Related calculators