EKS Max Pods per Node Calculator

The ENI max-pods formula, explained

Every EKS worker node runs the Amazon VPC CNI plugin, which assigns each pod a real routable IP address from the node's VPC subnet — there's no overlay network involved by default. That means pod capacity is bounded by how many IP addresses a node's network interfaces can hold, not by CPU or memory. AWS captures this per-instance-type limit as two numbers: the maximum number of Elastic Network Interfaces (ENIs) the instance supports, and how many IPv4 addresses each ENI can carry.

The standard formula is ENIs × (IPv4 per ENI − 1) + 2. One IP per ENI is reserved for the ENI's own primary address, and the +2 accounts for the two pods that use the host's own network namespace instead of consuming a VPC IP. This calculator sources its ENI and IP-per-ENI data directly from the dataset AWS ships inside amazon-eks-ami — the same source of truth max-pods-calculator.sh and nodeadm use internally.

Prefix delegation: ~16x more pods per node

Without prefix delegation, the VPC CNI attaches IPs one at a time, so pod density is capped by how many individual IPs an ENI can hold — often well under 50 on smaller instances. Prefix delegation changes the unit of allocation: instead of a single IP, each ENI slot gets a /28 prefix (16 contiguous IPv4 addresses) in one API call. That multiplies effective IP capacity by roughly 16x, which is why a t3.medium jumps from 17 pods to a kubelet-capped 110.

Two things temper that multiplier. First, prefix delegation only works on Nitro-based instance types — this calculator disables the toggle automatically on older Xen-hypervisor instances. Second, the kubelet itself enforces a hard ceiling regardless of how large the ENI math gets: 110 pods on instances with 30 vCPUs or fewer, 250 on larger ones. Large instances routinely hit this kubelet cap well before they'd run out of IP addresses — the calculator flags exactly when that happens.

Why pods get stuck in ContainerCreating

• IP exhaustion, not resource pressure. A node can show plenty of free CPU and memory while every pod slot is IP-starved — the scheduler placed the pod, but the CNI can't attach it to the network.
• ENI attachment lag. When warm IP/ENI pools run dry, the CNI has to call EC2 to attach a new ENI or allocate a new prefix, which can take tens of seconds — long enough for kubectl describe pod to show a stream of FailedCreatePodSandBox events.
• Bootstrap flag mismatches. Setting --max-pods above what the instance's ENIs can actually support (via bootstrap.sh or a custom kubelet config) schedules pods that can never get an IP — this calculator's numbers are the real ceiling, not a suggestion.
• Secondary CIDR without custom networking configured correctly. Custom networking reserves one ENI for the node's primary interface; forgetting to account for that in kubelet's --max-pods causes the same starvation pattern under load.