How max pods is calculated on EKS
With the Amazon VPC CNI every pod gets its own IPv4 address from the VPC, so a node runs only as many pods as its network interfaces (ENIs) have addresses for. Each ENI keeps its primary address for itself, and two pods on every node - the VPC CNI (aws-node) and kube-proxy - use the node's own address. The EKS-optimized AMI therefore sets the kubelet's maxPods to:
maxPods = ENIs × (IPv4 addresses per ENI − 1) + 2 An m5.large has 3 ENIs with 10 addresses each: 3 × 9 + 2 = 29 pods. On instances with several network cards, the AMI counts only the ENIs of the default one.
What finally sets maxPods, from the highest precedence:
| Nodes | maxPods |
|---|---|
| Managed node group without a custom AMI | EKS calculates it, with prefix delegation too, and caps it: 110 on instances with fewer than 30 vCPUs, 250 on the others. It overrides a maxPodsExpression. |
| Self-managed nodes or a custom AMI | maxPods in the NodeConfig's kubelet config, else nodeadm's maxPodsExpression, else the formula above - which knows nothing of prefix delegation or custom networking. |
| EKS Auto Mode | The lower of 110 and ENIs × (IPv4 addresses per ENI − 1). |
Prefix delegation
With ENABLE_PREFIX_DELEGATION=true (VPC CNI 1.9.0 or later) the CNI assigns each address slot of an ENI a /28 prefix of 16 addresses instead of a single address, so the same instance has 16 times the addresses: an m5.large goes from 29 to 3 × 9 × 16 + 2 = 434. Only instances built on the AWS Nitro System take prefixes; the others keep single addresses. The subnet needs free contiguous /28 blocks, or the CNI logs InsufficientCidrBlocks even with free addresses left - a subnet CIDR reservation keeps space for them.
434 pods on a 2-vCPU node would not fit anyway: a managed node group caps it at 110, and on self-managed nodes AWS recommends the same 110 or 250 - which you have to set yourself, as the AMI's default stays at 29.
Custom networking
Custom networking puts pods in other subnets than the node (an ENIConfig per Availability Zone). No address of the primary ENI then goes to a pod, so one ENI fewer counts: (ENIs − 1) × (addresses − 1) + 2, and × 16 with prefix delegation. On self-managed nodes the AMI's default is then too high - pods above the limit are scheduled to the node but cannot get an address - so set maxPods.
Allocatable CPU and memory
Not all of a node goes to pods. The EKS-optimized Amazon Linux 2023 AMI reserves for the kubelet and the container runtime (kubeReserved):
- CPU: 6% of the first core, 1% of the second, 0.5% of the third and fourth, 0.25% of every further core - 70m on 2 vCPUs, 90m on 8.
- Memory: 11 MiB per pod + 255 MiB, from the
maxPodsnodeadm calculates with the formula above - 574 MiB on anm5.large- even whenmaxPodsis set to another value. - 1 GiB of ephemeral storage.
The kubelet also evicts pods when less than 100 MiB of memory is free, so allocatable memory is the node's memory minus both. The calculator starts from the instance type's full memory; the node's operating system sees somewhat less, so the real allocatable memory is a little lower - kubectl describe node shows it. Auto Mode and Bottlerocket nodes reserve differently.
ECS tasks in awsvpc network mode
On ECS with EC2 instances, every task in awsvpc network mode gets an ENI of its own, and the instance's primary ENI counts toward the limit: an instance with 3 ENIs runs 2 such tasks, however much CPU and memory it has left. With the awsvpcTrunking account setting, a newly launched Linux instance of a supported type gets a trunk ENI and many more tasks - a c5.large goes from 2 to 10. Trunking needs container agent 1.28.1 or later, is not available on Windows, and some types and families are not supported; the calculator shows the limits from AWS's table. Fargate is not limited this way: each task has its own ENI.
Frequently asked questions
Why is max pods 110 on my node?
110 is the managed node group cap for instances with fewer than 30 vCPUs - and the Kubernetes default. With prefix delegation on a small Nitro instance the addresses allow more, but the cap wins.
Why do pods on a node not get an IP address?
Either the node's maxPods is higher than its addresses allow (custom networking with the default maxPods), or the subnet has no free addresses or, with prefix delegation, no free /28 blocks left. Compare the pods per node above with the node's .status.capacity.pods.
Does IPv6 change max pods?
On an IPv6 cluster the VPC CNI assigns a /80 prefix, so addresses stop being the limit; the kubelet's maxPods - the same cap or the value you set - is. IPv6 needs Nitro or bare metal instances.
Where does the data come from?
ENIs, addresses, vCPUs and memory per instance type from the file the EKS-optimized AMI itself uses to set maxPods, Nitro from the EC2 documentation and the ECS task limits from the ECS documentation - all read again on every build of this site, last on 2026-09-28.
Is what I enter sent anywhere?
No. The calculation runs in your browser. The page only counts that the calculator was used, with the node kind and CNI options chosen, never the instance type.
References
How maxPods is determined (Amazon EKS User Guide)
Increase the available IP addresses for your Amazon EKS node (Amazon EKS User Guide)
Prefix mode for Linux (Amazon EKS Best Practices Guide)
Deploy pods in alternate subnets with custom networking (Amazon EKS User Guide)
instance-info.jsonl and nodeadm (awslabs/amazon-eks-ami)
Instances built on the AWS Nitro System (Amazon EC2)
Increasing Amazon ECS Linux container instance network interfaces (Amazon ECS)
Supported instances for increased ECS container network interfaces (Amazon ECS)