Optimize EKS costs with AWS VPC CNI Prefix Delegation

Dealing with underutilized Amazon EKS nodes? If your cluster’s capacity reports a node like this—CPU at 18%, memory at 22%, and all 29 pods scheduled—you’re paying for resources that can’t even run your workloads. The bottleneck isn’t compute; it’s networking. Amazon’s default VPC CNI plugin assigns one IP per pod, tying pod scaling to the number of available Elastic Network Interfaces (ENIs) and secondary IPs on each EC2 instance.

This limitation forces Kubernetes to spin up new nodes when existing ones run out of IPs, even if CPU and memory remain underused. The result? Rising EC2 bills and inefficient resource utilization. Fortunately, there’s a solution built into the same plugin: Prefix Delegation. When enabled, it replaces single IPs with /28 blocks (16 contiguous IPs per ENI), unlocking far more pods per node without touching application code.

How EKS node networking really works

Every EKS worker node is an EC2 instance with Elastic Network Interfaces attached. Each ENI provides one primary IP (for the node) and multiple secondary IPs (for pods). The Amazon VPC CNI plugin, deployed as the aws-node DaemonSet, handles IP allocation dynamically. When a pod starts, the plugin requests a secondary IP from EC2 and assigns it directly to the pod—no virtual IPs or NAT involved.

This design has a hidden cost: the maximum number of pods per node depends on the instance type’s ENI limit and secondary IPs per ENI. AWS documents these caps in the EC2 instance type guides. For example, an m5.large instance supports 3 ENIs with 10 secondary IPs each, yielding a theoretical maximum of 29 pods once you subtract system pods like kube-proxy and aws-node.

The traditional formula reflects this constraint:

MaxPodsPerNode = (ENIs × (IPsPerENI − 1)) + 2

Plugging in the m5.large numbers gives 29 pods—even if the node has spare CPU and memory. If your workloads are lightweight, you’re effectively paying for unused capacity.

Why Prefix Delegation changes the game

Prefix Delegation redefines how the VPC CNI plugin requests IPs. Instead of claiming one IP at a time, it enrolls /28 prefix blocks (16 IPs) per ENI slot. This shifts the formula to:

MaxPodsPerNode = ENIs × ((IPsPerENI − 1) × 16) + 2

For an m5.large, that jumps from 29 to 434 pods in theory. In practice, Kubernetes and EC2 impose additional limits, but the ceiling rises dramatically. The real-world impact? You can consolidate workloads onto fewer nodes, reduce over-provisioning, and cut EC2 spend by up to 75%—all without modifying your applications.

Step-by-step: Enabling Prefix Delegation

Activating Prefix Delegation requires two changes. First, update the VPC CNI add-on by adding these environment variables to its configuration:

{
  "env": {
    "ENABLE_PREFIX_DELEGATION": "true",
    "WARM_PREFIX_TARGET": "1"
  }
}

Second, you must tell kubelet to recognize the new pod capacity. The plugin won’t auto-adjust maxPods in kubelet, so you risk pods failing with errors like Too many pods, 0/N nodes are available if you skip this step.

For Karpenter clusters

Karpenter defaults to a conservative 110-pod limit and doesn’t auto-calculate limits based on Prefix Delegation. Override it in your NodePool spec:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      kubelet:
        maxPods: 110

Karpenter skips its built-in max-pods-calculator.sh script when maxPods is explicitly set. Note that the script still uses the legacy secondary-IP formula, so manual adjustment is necessary.

For Managed Node Groups

Bootstrap scripts need an override for kubelet’s maxPods parameter. Update the cluster launch command:

export CLUSTER_NAME="my-cluster"
/etc/eks/bootstrap.sh $CLUSTER_NAME \
  --use-max-pods false \
  --kubelet-extra-args '--max-pods=110'

This disables the default calculation and sets a fixed ceiling across the node group.

Respecting Kubernetes scalability thresholds

Even with expanded IP capacity, Kubernetes enforces internal guardrails to prevent scheduler overload. The key rule is:

maxPods = min(110, 10 × #cores)

This cap ensures the node’s kernel can manage process scheduling without degradation. For an m5.large with 2 vCPUs, the limit is 20 pods. Prefix Delegation alone won’t override this—you must reconcile it with your chosen maxPods value.

After applying both constraints, the effective max pods for an m5.large becomes 110 (the higher value between the Kubernetes threshold and the VPC CNI formula). For larger instances like m5.4xlarge, the cap remains 110 until you scale beyond 4 cores, after which it rises to 250.

When Prefix Delegation isn’t worth the switch

Prefix Delegation shines for workloads with small to medium resource footprints. If your pods routinely demand more than 1 vCPU or 2 GiB of RAM, the bottleneck shifts from networking to compute. In those cases, enabling Prefix Delegation won’t reduce node count or costs—it may even introduce latency from increased ENI traffic.

Other scenarios to avoid:

• Nodes running stateful services with strict IP affinity requirements.
• Clusters using custom CNI plugins that don’t support prefix delegation.
• Environments where ENI limits already constrain other services (NAT gateways, RDS proxies).

Before flipping the switch, benchmark your current pod density and compare it against the projected savings. Tools like Amazon CloudWatch Container Insights can help measure underutilized resources across your EKS fleet.

The path to smarter EKS spending

Amazon EKS gives you powerful tools to optimize cloud spend, but default configurations often hide inefficiencies. Prefix Delegation in the VPC CNI plugin is a prime example—it turns idle ENI capacity into usable pod slots, letting you right-size clusters without rewriting a single line of code. The real work lies in tuning kubelet and validating against Kubernetes thresholds, but the payoff can be substantial.

Start small: enable Prefix Delegation on a non-production node group, monitor pod density and costs, then scale your changes. With the right configuration, you could see your EC2 bill drop while maintaining—or even improving—application performance.