Understand node ENI limits
Each EC2 instance type supports a specific number of ENIs and IP addresses.
For example, an m5.large node can support:

• 29 primary IPs, plus

• 2 × 31 secondary IPs

  If the node exceeds its maximum supported IPs, Kubernetes cannot assign an IP to the pod, which triggers the pod sandbox error.

Avoid using a static --max-pods value
If your virtual node group uses a hard‑coded value (for example, the AWS default of 110), the node may allow more pods than it can assign IP addresses for.
Static values often cause:

• Overutilization (too many pods, not enough IPs)

• Underutilization (wasted capacity if the value is too low)

Use the dynamic max-pods calculator script
Create a script to dynamically calculate the correct --max-pods value based on the instance type and CNI version at runtime.

Example:

CNI_VERSION=<such as 1.11.4-eksbuild.1> MAX_PODS=$(/etc/eks/max-pods-calculator.sh --instance-type-from-imds --cni-version $CNI_VERSION)

• --instance-type-from-imds automatically retrieves the instance type from IMDS.

• --cni-version ensures calculation matches your CNI plugin version.

Update your virtual node group user data
If your user data doesn’t define --max-pods, AWS defaults the value to 110, which is often incorrect.
Instead:

• Add the dynamic calculated value to user data, or

• Remove static values to avoid misconfiguration.

Restart the node or scale the group
After updating user data or recalculating --max-pods, cycle the nodes so the new configuration takes effect.