Networking: VPC CNI

Every lab so far has run on Calico, an overlay network: pod IPs come from a virtual address space (192.168.0.0/16 on your cluster) that Calico tunnels across your 3 nodes, with no relationship to your Mac's real network. EKS does something fundamentally different, and it's the first thing that surprises people moving from kind/minikube to production AWS.

VPC CNI: pods get real VPC IPs

The Amazon VPC CNI plugin — EKS's default — gives every pod a real, routable IP address from your VPC subnet, allocated from the ENI (Elastic Network Interface) attached to the pod's node. No overlay, no tunnel: a pod's IP is a first-class citizen of your VPC, visible to anything else in it exactly like an EC2 instance's IP would be. That's genuinely useful — pods can talk directly to RDS, other VPC resources, and on-prem networks over Direct Connect/VPN without any extra NAT layer.

Your kind cluster vs. a real EKS cluster

	Your kind cluster	Real EKS
Networking	Calico overlay — pod IPs from an arbitrary virtual range (192.168.0.0/16), tunneled between nodes	VPC CNI — pod IPs from your real VPC subnet via ENIs, routable like any EC2 instance
Ingress / LB	Traefik, Service type ClusterIP — no real external address	AWS Load Balancer Controller provisions a real NLB/ALB from Service/Ingress annotations
Storage	local-path-provisioner — a directory on the node's own disk	EBS CSI driver — a real, network-attached EBS volume (or EFS CSI for shared access)
Identity for pods	No cloud IAM — nothing to authenticate to	IRSA or Pod Identity — a ServiceAccount maps to a real IAM role

The IP-exhaustion problem this creates

Because every pod consumes a real IP from the subnet, and every node reserves IPs up front for the pods it might run, small subnets run out of IPs surprisingly fast — a problem that simply doesn't exist with an overlay network like Calico, where the pod address space is independent of your VPC's CIDR entirely. The standard mitigation is prefix delegation: instead of attaching IPs to an ENI one at a time, the node reserves whole /28 prefixes (16 IPs each), dramatically raising the max-pods-per-node ceiling for a given instance type without needing more ENIs. It's a config flag on the VPC CNI plugin, not something you write into your own manifests — but it's exactly the kind of setting you'll need to know about the first time kubectl describe pod shows a scheduling failure that traces back to "no IPs available," not CPU or memory.

What carries over, what doesn't

NetworkPolicies, Services, and DNS all work identically on top of VPC CNI — the Kubernetes API doesn't change. What's different is purely how the data plane assigns and routes addresses underneath. Any NetworkPolicy you write using CIDR blocks (ipBlock), though, needs to reflect your VPC's real subnet ranges on EKS — not an arbitrary overlay range you picked, since there is no overlay range anymore. You'll fix exactly this kind of CIDR mismatch in this lesson's lab, using the real pod subnet your own cluster already runs on (192.168.0.0/16) as the stand-in for "the subnet you'd actually need to know in production."

The infrastructure analogy

If you've worked with traditional VPC networking or ENI-per-instance quotas in EC2, VPC CNI is that exact same mental model, just applied per pod instead of per instance — which is precisely why it inherits EC2's IP-planning headaches at a much higher density.