Running Amazon EKS at a larger scale can lead to issues with IP address limits, which affects how many pods can run on a node. This happens because EKS uses EC2 network interfaces that have fixed IP limits.

Prefix Delegation is a feature in the AWS VPC CNI plugin that helps address this by allowing more pods to run on each node. In this post, we’ll explain what Prefix Delegation is, how it works, how to enable it, and the benefits it provides.

Why Prefix Delegation?

---

In a traditional EKS setup, each pod gets a single secondary IP. That works fine—until your workloads scale, and suddenly your node is out of IPs before it’s out of CPU or memory.

In the following example, we'll use m5.large instance type that has 3 ENIs and 10 IP addresses per network interface.

❗The number of ENIs and IP addresses per interface differes between different EC2 instance types. You can find the specs for each EC2 type here

Let’s break it down with a familiar EC2 instance, like m5.large:

• Without Prefix Delegation (Traditional):

  • 3 ENIs × 10 secondary IPs = 30 pod IPs (minus 1 for the node) → ~29 pods

❗You will not get 3 ENIs from the beginning. AWS will increase the number of ENIs when you try to spin up more pods.

• With Prefix Delegation:

  • 3 ENIs × 9 prefixes × 16 IPs = 432 theoretical IPs → capped by Kubernetes at 110 pods

Every Elastic Network Interface (ENI) must have a Primary Private IPv4 Address to function on the network. This IP identifies the EC2 instance itself.

So instead of being bottlenecked at 29 pods per node, you hit the standard Kubernetes maximum of 110 pods per node—without changing instance type or networking configuration.

How Prefix Delegation Works

---

Prefix Delegation switches the unit of IP assignment from individual IPs to /28 IPv4 prefixes (each containing 16 IP addresses).

Here’s how the lifecycle works inside EKS:

1. aws-node DaemonSet requests /28 prefixes from your subnet

2. AWS assigns those prefixes to the node’s ENIs

3. The VPC CNI allocates pod IPs from the assigned prefixes

4. A “warm” pool of unused prefixes is maintained for faster scheduling

Key Configurations

To enable Prefix Delegation in your cluster, set the following environment variables in the aws-node DaemonSet:

- name: ENABLE_PREFIX_DELEGATION
  value: "true"
- name: WARM_PREFIX_TARGET
  value: "1"

For instance, if you deploy your EKS and the aws-node addon with AWS CDK, you could add it to your configuration like the following:

    new eks.Addon(this, 'AwsVpcCniAddon', {
      cluster: this.cluster,
      addonName: 'vpc-cni',
      addonVersion: 'v1.21.1-eksbuild.1',
      preserveOnDelete: false,
      configurationValues: {
        env: {
          ENABLE_PREFIX_DELEGATION: 'true',
      },
    });

Setting WARM_PREFIX_TARGET=1 creates a 'buffer' of ready-to-use IP addresses on each node. 1 is the default value.

From the official doc: "The installation manifest’s default value for WARM_PREFIX_TARGET is 1. In most cases, the recommended value of 1 for WARM_PREFIX_TARGET will provide a good mix of fast pod launch times while minimizing unused IP addresses assigned to the instance."

Specifically, it ensures that one full block of 16 IPs (a /28 prefix) is always attached and on standby, even if it's not currently being used. When your application scales up and needs to launch new Pods, they can grab an IP from this 'warm' pool instantly instead of waiting for the network interface to attach. This eliminates the 'startup lag' during traffic spikes while preventing us from hoarding too many unused IP addresses.

You can technically set the WARM_PREFIX_TARGET value to whatever number you like, but the physical limit on an m5.large instance is 27 prefixes.

Here is the breakdown of why 27 is the hard ceiling and how the setting behaves:

An m5.large instance has 3 ENIs, and each ENI has 10 slots:

• Slot 0: Occupied by the ENI's Primary IP (Required).

• Slots 1-9: Available for Prefixes.

Total Capacity: 3 ENIs x 9 Prefixes = 27 Prefixes Total

❗It will only apply to the new node groups, so you need to recreate any node groups where you want Prefix Delegation to be enabled.

Real-World Pod Capacity Boost

---

After enabling Prefix Delegation, node pod counts look very different:

kubectl get nodes -o custom-columns=NAME:.metadata.name,TYPE:.metadata.labels.node\\.kubernetes\\.io/instance-type,PODS:.status.capacity.pods

Output:

NAME                                      TYPE       PODS
ip-10-0-2-22.eu-west-1.compute.internal   m5.large   110 <<<< PREFIX DELEGATION
ip-10-0-2-30.eu-west-1.compute.internal   m5.large   29
ip-10-0-2-81.eu-west-1.compute.internal   m5.large   29

This shows a clear improvement: older instance types cap out at 11–35 pods, while prefix-enabled nodes max out at 110 pods—the Kubernetes default.

Confirming Prefix Delegation is Active

---

Here are a few quick checks:

1. Check DaemonSet configuration

kubectl set env daemonset/aws-node -n kube-system --list | grep PREFIX

2. Look at the node capacity

kubectl get nodes -o custom-columns=NAME:.metadata.name,INSTANCE_TYPE:.metadata.labels.node\\.kubernetes\\.io/instance-type,ALLOCATABLE_PODS:.status.allocatable.pods

You should see ALLOCATABLE_PODS: 110 on prefix-enabled nodes.

3. Inspect EC2 ENIs

aws ec2 describe-network-interfaces --network-interface-ids <eni-id>

Look for Ipv4Prefixes instead of PrivateIpAddresses:

"Ipv4Prefixes": [
    { "Ipv4Prefix": "10.0.45.16/28" },
    { "Ipv4Prefix": "10.0.45.32/28" }
]

When Prefix Delegation is active, the ENI’s IP listing will show /28 CIDR blocks instead of individual IP addresses.

Cost and Scaling Benefits

---

Prefix Delegation doesn’t just boost pod capacity—it can dramatically reduce infrastructure cost and improve operational flexibility.

Instance Type	Without Prefix	With Prefix	Node Cost Reduction
t3.small	11 pods	110 pods	90% fewer nodes
m5.large	29 pods	110 pods	73% fewer nodes

Assuming you’re running an app that requires 400 pods:

• Without Prefix Delegation: 400 / 29 = ~14 nodes

• With Prefix Delegation: 400 / 110 = ~4 nodes

This is a ~70% savings on EC2 costs alone, not to mention:

• Fewer EBS volumes

• Lower NAT Gateway charges

• Reduced log volume and monitoring overhead

• Simpler IP planning

When (and Not) to Use Prefix Delegation

---

While Prefix Delegation is a powerful feature, it changes how your cluster consumes IP addresses. It is not always a "fire and forget" setting.

Use it if:

• You have large subnets: Your subnets are /22 or larger, so you can afford to "spend" IPs in blocks of 16 without running out.

• You use Custom Networking: You are using the AWS VPC CNI with Custom Networking (secondary CIDR blocks like 100.64.0.0/10). This gives you a massive separate pool of IPs just for pods, isolating them from your node IP space.

• You need density: You are running high-density workloads (like small microservices or batch jobs) and hitting the ENI limit on your nodes.

⚠️ Be careful (or avoid) if:

• You have small subnets: If you are running on standard /24 subnets (254 IPs), Prefix Delegation can exhaust your IP space extremely fast.

  • Why? Each node grabs a full /28 block (16 IPs) immediately. Launching just 10 nodes will consume 160 IPs instantly, leaving little room for error.

• Legacy IP Constraints: Your organization has strict IP quotas or limited private IPv4 space.

💡Tip: If you are constrained by IP space but need high density, the architectural "fix" is to implement EKS Custom Networking using CGNAT ranges. This allows you to enable Prefix Delegation safely without exhausting your primary VPC subnets. You can read more about setting up Custom Networking in the AWS Best Practices guide.

Useful Commands

---

Check the IP Prefixes for a specific EC2 Instance (don't forget to set the INSTANCE_ID variable):

aws ec2 describe-network-interfaces \
  --region eu-west-1 \
  --filters "Name=attachment.instance-id,Values=$INSTANCE_ID" \
  --query 'NetworkInterfaces[*].[NetworkInterfaceId, Ipv4Prefixes[*].Ipv4Prefix]' \
  --output json

Final Thoughts

---

Prefix Delegation allows you to run 3–10× more pods on your existing nodes. This prevents you from paying for extra EC2 instances just to get more IP addresses, and potentially letting you fully use the CPU and memory you are paying for.

However, use it with caution.

Because this feature reserves IPs in blocks of 16 (rather than individual Secondary IPs), it consumes network space much faster.

Before enabling this, verify that your subnets have plenty of free space or set up secondary IP ranges to handle the load. If your network has the room, this is a great way to cut costs and maximize efficiency.

References

---

Prefix Mode for Linux: https://docs.aws.amazon.com/eks/latest/best-practices/prefix-mode-linux.html

EC2 general purpose instances:  https://docs.aws.amazon.com/ec2/latest/instancetypes/gp.html#gp_network

Custom Networking: https://docs.aws.amazon.com/eks/latest/best-practices/custom-networking.html

IPv6 addresses to clusters, Pods, and services:  https://docs.aws.amazon.com/eks/latest/userguide/cni-ipv6.html