Module 3

Networking

On EKS the default network plugin gives every Pod a real IP address from your VPC subnets. That makes networking simple and powerful, and makes IP capacity a first-class design concern.

Why it matters. Running out of subnet IPs, cross-AZ data charges and misrouted load balancers are the classic EKS networking incidents. All of them are predictable from the model.

After this module you can answer

How many Pods fit on one node, and why?
What do prefix delegation and custom networking fix?
When do I use security groups for pods versus NetworkPolicy?
ALB or NLB, and what is IP target mode?
Gateway API or VPC Lattice for traffic between clusters?

What is inside

1VPC CNI model

2IP capacity fixes

3Security groups and policy

4AWS Load Balancer Controller

5Gateway API on EKS

6VPC Lattice

7Private clusters and endpoints

8Cross-AZ traffic

9Module infographic

Networking: pods are VPC citizens

Module 3 builds on the Kubernetes networking model from Deck 1. There, the network plugin (CNI) was an abstract box. On EKS it has a concrete default: the Amazon VPC CNI, which attaches ENIs to nodes and hands their secondary IP addresses to Pods, so a Pod is directly addressable in your VPC with no overlay.

That has big upsides, including native VPC routing, security groups and flow logs for Pods, and one big caveat: Pod IPs come out of your subnets, so IP planning matters. We cover the fixes, then how traffic enters through the AWS Load Balancer Controller, the Gateway API options, and cross-cluster connectivity with VPC Lattice.

Compare with GKE in Deck 2, which uses alias IP ranges, and with overlay CNIs such as Calico or Cilium in cluster-pool mode in Deck 7, which hide Pod IPs from the VPC.