AWS EKS Support
EKS VPC CNI IP exhaustion: fix pod IP and max-pods limits.
By default each EKS pod gets a real VPC IP address from the node's network interfaces. That means subnets can run out of addresses and nodes hit a maximum pod count set by instance type. Both show up as Pending pods or failed pod sandbox creation, and both are fixable.
When You Need This
The situations where this work pays for itself.
Signs it is time
- Pods are Pending with failed to assign an IP address to container
- Subnets show very few free IPs
- Nodes cannot run more pods than a low maximum despite spare CPU and memory
- You are about to scale a cluster and the subnets are small
- The cluster shares a VPC and CIDR space with many other teams
What you get
- Diagnosis of whether subnet space or max pods is the limit
- VPC CNI configuration and node group changes in code
- Secondary CIDR and custom networking design if needed
- Monitoring of free IPs per subnet
How we do it
A clear, safe process you can follow along with.
1. Confirm the symptom
Pod events show failed to assign an IP address to container or similar, and the aws-node (VPC CNI) logs and ipamd log under /var/log/aws-routed-eni show allocation errors such as InsufficientFreeAddressesInSubnet. We compare the node's pod count with its maximum.
2. Measure subnet capacity
We check free IPs in each node subnet, and how many are held by warm IPs on nodes that are not running pods. By default the CNI keeps a warm pool of IPs and ENIs on each node, which consumes addresses.
3. Tune the warm pool
Settings such as WARM_IP_TARGET, MINIMUM_IP_TARGET and WARM_ENI_TARGET reduce idle addresses per node. We balance this against pod start latency and EC2 API call volume, so it is changed carefully and tested.
4. Raise the max pods per node with prefix delegation
On Nitro instances, enabling ENABLE_PREFIX_DELEGATION assigns /28 prefixes to ENIs, which supports many more pods per node. It needs contiguous free space in the subnet and a maximum pods value set on the nodes, which for managed node groups we configure in the launch template.
5. Add address space with custom networking
If subnets themselves are exhausted, we associate a secondary CIDR such as one from 100.64.0.0/10 to the VPC, create pod subnets and ENIConfig resources, and enable custom networking so pods draw from the new range while nodes keep primary addresses.
6. Consider IPv6
For new clusters, an IPv6 EKS cluster avoids IPv4 exhaustion entirely. It cannot be switched on for an existing cluster, so we plan it for a rebuild or migration.
7. Verify and monitor
We roll the nodes to apply settings, confirm pods schedule at the new density, and add alarms on free subnet IPs and on pending pods.
Mistakes we help you avoid
Common ways this goes wrong, and what we do instead.
Enabling prefix delegation in fragmented subnets
Allocation fails if no contiguous /28 is available. We check or use new subnets.
Setting warm targets too low
Pods then wait for IP allocation on scale-up.
Adding subnets but forgetting node group config
Nodes do not use the new subnets until the group is updated.
Changing CNI settings without rolling nodes
Some settings only apply to newly launched nodes.
Frequently Asked Questions
Why does EKS limit the number of pods per node?
With the VPC CNI, pods consume IPs from the node's ENIs, and each instance type supports a limited number of ENIs and IPs per ENI, which sets the default max pods.
What is prefix delegation?
It assigns blocks of IP addresses to an ENI instead of single addresses, so a node can host many more pods per ENI on supported Nitro instance types.
Can I add more subnets to an EKS cluster?
Yes. You can add secondary CIDR blocks and subnets to the VPC and use custom networking or new node groups, which is usually safer than rebuilding the cluster.
Want Help With EKS VPC CNI IP exhaustion: fix pod IP and max-pods limits?
Schedule an appointment. Tell us about your environment and we will outline the safest, highest-value approach.
Schedule Appointment › No commitment required