A cluster gives every pod a routable address from the VPC. The VPC is a /16, each node is allocated a /24 for its pods, and nodes run up to 110 pods. The platform team plans for 400 nodes. Work out when addresses run out and what the options cost.

The assumptions, stated

A /16 holds 65,536 addresses. A /24 holds 256, of which 251 or so are usable once the network, broadcast and provider-reserved addresses are taken. One /24 per node means the limit is the number of /24s in the VPC, not the number of addresses: 65,536 / 256 = 256.

The arithmetic

The cluster hits a wall at 256 nodes, well before the 400 planned - and it is not an address shortage, it is a prefix shortage. Each node is burning 256 addresses to host at most 110 pods, so utilisation is under 43% by construction and more than half of the VPC is reserved for pods that will never exist.

Worse, the /16 is not all available to the cluster. Subnets for load balancers, databases, endpoints and other workloads come out of the same space, and most estates reserve ranges per environment. A realistic allocation leaves perhaps half of it, so the wall arrives nearer 120 nodes.

The per-node demand that would actually fit: 110 pods needs 128 addresses, a /25. At a /25 per node, 400 nodes consume 51,200 addresses - 78% of the /16, which is feasible and uncomfortable.

The options, with their costs

• Right-size the per-node prefix. A /25 or /26 per node matched to the real pod density is the cheapest fix and requires no new technology. It costs flexibility: a node that needs more pods than its prefix allows cannot get them, and raising density later means re-provisioning nodes.
• Prefix delegation. Rather than one large block per node, the CNI assigns small prefixes - /28 blocks of 16 addresses in the AWS VPC CNI's implementation - on demand as pods are scheduled. Allocation then tracks actual density instead of the worst case, and the per-node waste falls from 146 addresses to at most 15. It costs some scheduling latency when a new prefix is needed and requires contiguous space to allocate from, which a fragmented VPC may not have.
• Add a secondary CIDR to the VPC and put the node subnets in it. Cheap, fast and the usual production answer, with one condition that bites later: the secondary range must not collide with anything the estate may ever peer with or connect by VPN. A chosen-for-convenience range is how two business units end up both using 10.0.0.0/16.
• Overlay networking. Pods get addresses from a private range that is not routable in the VPC, so the cluster's address needs disappear from the estate's plan. It costs the property that made the flat design attractive: direct reachability from other VPC resources, straightforward security-group semantics for pod traffic, and the encapsulation overhead - a few per cent of throughput and a reduced effective MTU that interacts badly with path MTU discovery.

Which assumption dominates the error

Real pod density per node, not node count. Teams plan on the maximum - 110 - while actual density is frequently 20 to 40, and a measurement before the decision changes which option is right. The second dominant assumption is how much of the /16 the cluster may actually use, which is an estate question rather than a cluster one.

What the number rules in or out

It rules out "we have a /16, we have plenty of addresses" as a planning statement: the capacity question for a flat pod network is prefixes, not addresses. It rules in a standing metric - allocated addresses as a share of the VPC, and allocated-versus-used per node - because exhaustion arrives as pods stuck in a pending state during an autoscaling event, which is the worst moment to be reading CNI documentation.

When this is the wrong analysis

For a cluster that will stay under 30 nodes, this arithmetic is a distraction: take the default, keep a /20 of spare space in the estate's plan and move on. Prefer the flat routable design while it fits, because it is the one where security groups, flow logs and direct reachability behave the way everyone expects. The honest trigger for the overlay conversation is not node count but estate scarcity - when a second business unit needs space in the same private range, or when a merger brings overlapping networks, the pod addresses are the first thing worth taking off the shared plan.