PacketSensei

AWS `failed to assign an IP address to container`: What It Means and How to Fix It

PacketSensei

failed to assign an IP address to container is the AWS VPC CNI running out of addresses — either the subnet is full or the node is at its ENI limit. It comes from EKS, and the message reads:

failed to assign an IP address to container / add cmd: failed to assign an IP address to container

If you are here mid-incident, skip to how to tell which cause you have — the command there narrows it down faster than reading the list.

Quick reference
Error failed to assign an IP address to container
Service EKS
Message failed to assign an IP address to container / add cmd: failed to assign an IP address to container
Most common cause The subnet has no free addresses

What it actually means

Pods stay in ContainerCreating and the kubelet event shows this message. The AWS VPC CNI gives every pod a real VPC address, so “out of pod IPs” means one of two exhaustions:

  1. The subnet is out of addresses. Nothing more can be allocated to any node in it.
  2. The node is at its ENI and address limit. Each instance type supports a fixed number of ENIs and a fixed number of addresses per ENI. An m5.large supports 3 ENIs × 10 addresses = 29 usable pod addresses, no matter how much CPU and memory are free.

The two need different fixes, and AvailableIpAddressCount on the subnet tells you which one you have in one command.

Why it happens

Ranked by how often each one turns out to be the answer.

# Cause Fix
1 The subnet has no free addresses Check AvailableIpAddressCount. Subnets cannot be resized, so the fix is new, larger subnets — or a secondary VPC CIDR from 100.64.0.0/10 when RFC 1918 space is gone.
2 The node is at its per-instance address limit Enable prefix delegation, which assigns /28 prefixes to each ENI instead of individual addresses. An m5.large goes from 29 pods to 110 — in practice the kubelet’s maxPods becomes the binding limit rather than the address count. This is usually the right first move.
3 WARM_IP_TARGET or WARM_PREFIX_TARGET set too high The CNI pre-allocates addresses to speed up pod start. Set aggressively across many nodes, it consumes the subnet without any pods running.
4 Custom networking configured incorrectly With AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true, pods take addresses from the ENIConfig subnet, not the node subnet. A missing or mislabelled ENIConfig for one availability zone fails only in that zone.
5 Orphaned ENIs from deleted nodes Rare, but leaked CNI interfaces hold addresses. They appear as available ENIs with a node.k8s.amazonaws.com/instance_id tag.

How to tell which one you have

# 1. Is the subnet out, or the node?
aws ec2 describe-subnets --subnet-ids subnet-0123456789abcdef0 \
  --query 'Subnets[].[CidrBlock,AvailableIpAddressCount]' --output text

# 2. What does the CNI say on the affected node?
kubectl logs -n kube-system -l k8s-app=aws-node --tail=100 | grep -i 'ip address|ENI'

# 3. Is prefix delegation on?
kubectl get ds aws-node -n kube-system \
  -o jsonpath='{.spec.template.spec.containers[0].env[?(@.name=="ENABLE_PREFIX_DELEGATION")].value}'

# 4. Orphaned ENIs holding addresses?
aws ec2 describe-network-interfaces \
  --filters Name=status,Values=available Name=tag-key,Values=node.k8s.amazonaws.com/instance_id \
  --query 'NetworkInterfaces[].NetworkInterfaceId' --output text

Preventing it

Turn on prefix delegation before you need it:

kubectl set env daemonset aws-node -n kube-system ENABLE_PREFIX_DELEGATION=true
kubectl set env daemonset aws-node -n kube-system WARM_PREFIX_TARGET=1

Then size worker subnets for pods rather than nodes — /19 or /20 per availability zone is normal — and alarm on AvailableIpAddressCount dropping below 10% so exhaustion is a warning rather than an outage.

Quota codes, limits and behaviour on this page were last checked against AWS documentation on 2026-08-22. AWS changes these; if something here does not match what you are seeing, trust the console and tell us.