Maximizing Amazon EKS Pod Density: Why Karpenter Ignores AWS's Default Limits

1. What happens by default in normal EKS nodes

When you launch an Amazon EKS node, either through Managed Node Groups or a self-managed Amazon EC2 instance, the startup script: /etc/eks/bootstrap.sh runs automatically. This script makes the node join the cluster and sets important kubelet parameters.

By default, the script calculates how many pods a node can run based on the instance type and the number of ENIs (network interfaces) available.

When --use-max-pods=true, the script internally calls /etc/eks/max-pods-calculator.sh to find the right value based on ENI and IP limits. For example, an m5.large instance might be assigned --max-pods=29.

This is the safe and recommended behavior by AWS for standard EKS clusters that use the default Virtual Private Cloud (VPC) CNI plugin.

2. When we set --use-max-pods=false

If we configure the bootstrap script like this:

The script skips the ENI-based calculation and uses the provided value directly. That means the kubelet will allow up to 110 pods on that node, regardless of ENI limits.

This is only safe if your networking setup supports that many IPs, for example, when you are using prefix delegation or a custom CNI.

3. What user data Karpenter uses by default for AL2 AMI

Karpenter does not use the same default AWS user data. It automatically generates its own MIME-style user data for Amazon Linux 2 nodes.

Here is the default format from the Karpenter documentation:

By default, Karpenter sets --use-max-pods=false and defines --max-pods=110 for every AL2 node it launches.

4. Why Karpenter disables auto-calculation

This behavior is intentional.

Karpenter disables the AWS max-pods-calculator.sh because that script still uses the old Amazon ENI-based logic and does not account for prefix delegation, which increases the number of available IPs per ENI.

Since most modern Amazon EKS clusters now use prefix delegation by default, the calculator would assign a value that is too low.

To avoid this, Karpenter does the following: 

• Sets --use-max-pods=false to skip automatic calculation.
• Manually sets --max-pods=110 as a safe upper limit.
• Keeps node behavior consistent across all instance sizes.
• This makes pod density predictable and keeps networking stable.  

5. When to override this manually

You usually do not need to change Karpenter’s user data.

Only override it if:

• You are using a custom AMI that is not Amazon EKS optimized.
• You are using a non-VPC CNI like Calico or Cilium.
• You want to adjust pod density for specific workloads.

Example override in Amazon EC2NodeClass:

6. Best Practice Summary

7. Final takeaway

• For normal Amazon EKS nodes, keep --use-max-pods=true.
• For Karpenter, it is already false, and that is the correct setting.
• Do not mix both settings unless you fully understand your network limits.
• If you are unsure, stay with the default setting because it is tested and safe.

8. Quick check command

To verify what value your node is using, run:

• cat /etc/systemd/system/kubelet.service.d/10-kubelet-args.conf | grep max-pods

This command shows the active --max-pods value used by the kubelet.

9. How Karpenter supports prefix delegation mode

Prefix delegation is a feature in the Amazon VPC CNI plugin that allows each ENI to receive a small prefix, usually a /28 subnet, instead of individual secondary IPs.

Each prefix contains 16 IP addresses that the CNI can assign directly to pods without extra API calls to Amazon EC2. This improves IP allocation speed and lets each node handle more pods.

Karpenter supports prefix delegation completely, even though it sets --use-max-pods=false. It does this by staying out of the ENI-based calculation logic and letting the CNI handle IP management dynamically.

When Karpenter launches a node, it runs the bootstrap script with:

This means the bootstrap script does not run /etc/eks/max-pods-calculator.sh, which is still based on old ENI logic and does not understand prefix delegation. Instead, Karpenter sets a fixed kubelet limit of --max-pods=110, which is high enough for most instance types when prefix mode is active.

Prefix delegation itself is managed by the VPC CNI plugin, not by Karpenter. You enable it using the aws-node DaemonSet in the kube-system namespace by setting the following environment variables:

After enabling these, each node gets one or more /28 prefixes attached to its ENIs. The VPC CNI then assigns IPs to pods from those prefixes automatically. Karpenter does not need to calculate anything; it just ensures kubelet allows enough pods. This design separates responsibilities clearly:

With this setup, Karpenter nodes fully benefit from prefix delegation.

The VPC CNI handles pod IP assignment, and Karpenter ensures kubelet does not block scheduling too early with old ENI limits. This keeps the node setup simple, allows efficient pod density, and ensures the cluster uses modern VPC networking features properly.

Closing note

This flag may seem small, but it affects how efficiently your cluster uses each node.

Karpenter’s default configuration (--use-max-pods=false) is intentional and matches how Amazon EKS works with prefix delegation today. Avoid changing it unless there is a clear technical reason.