Pod capacity per node is set by how many ENIs and secondary IPs the instance type allows.

Each ENI holds a number of IPv4 addresses; the primary IP belongs to the node, the rest are handed to Pods.

Max Pods per node (default mode)

ENIs x (IPs per ENI - 1) + 2

m5.large: 3 x (10 - 1) + 2 = 29 Pods. Small instances run out of Pod slots long before CPU.

Why this design

No overlay or NAT: Pods use native VPC routing, security groups and flow logs, and are reachable from on-prem over Direct Connect.

The catch

Every Pod consumes a subnet IP. A big cluster in a small /24 subnet fails to schedule Pods long before CPU is full.

The VPC CNI gives each Pod a real address from its node's ENIs

The Amazon VPC CNI runs as a DaemonSet (aws-node) on every node. It attaches elastic network interfaces to the instance and keeps a pool of warm secondary IP addresses on them. When the kubelet starts a Pod, the CNI assigns one of those addresses to the Pod's network namespace. The Pod therefore has a real, routable VPC address, with no overlay or NAT in the way. Reveal the steps with the right arrow.

The number of ENIs and the number of IPs per ENI depend on the instance type, which is why Pod capacity differs. The formula shown (ENIs times IPs per ENI minus one, plus two) gives 29 Pods for an m5.large. In practice you often hit this limit before CPU or memory on small instance types, and EKS sets maxPods accordingly.

The upside of real VPC IPs is operational simplicity: security groups, flow logs, routing tables and AWS services can all see Pods directly, and on-premises systems connected over Direct Connect or VPN can reach them. The downside is that your subnets must be large enough, and that IP consumption scales with Pods rather than nodes. The next slide covers the standard fixes.

Comparison note: GKE VPC-native clusters assign Pod IPs from a secondary alias range that you size per cluster. Overlay CNIs can hide Pod IPs inside the cluster, trading VPC visibility for simplicity of IP planning.