EKS VPC CNI & Network Security

1. AWS VPC CNI: Why every Pod gets a native IP A CNI (Container Network Interface) is the plugin responsible for giving IP addresses to your Pods. Many standard Kubernetes setups use “Overlay” networks (like Flannel), which give Pods fake, virtual IP addresses that the actual cloud provider doesn’t understand.

EKS uses the AWS VPC CNI. It works differently. It talks directly to AWS and provisions real Elastic Network Interfaces (ENIs) and secondary IP addresses from your actual AWS Subnet, assigning them directly to your Pods.

• The Benefit: Because the Pod has a native AWS IP, it can natively route traffic to an AWS RDS database, it can be tracked by AWS VPC Flow Logs, and it performs incredibly fast without the overhead of “un-packaging” virtual network packets.

2. Network Policies: Layer 4 Zero-Trust Since all Pods can communicate by default, we need a virtual firewall inside the cluster. A Network Policy allows you to implement “Zero-Trust.” It operates at Layer 3/Layer 4 of the network (IP addresses and Ports).

• You can define a rule that says: “The Database Pod will drop all incoming traffic UNLESS it comes from a Pod with the label app: backend on Port 3306.”

3. The 2026 Feature: FQDN Egress Filtering For years, restricting outbound traffic (egress) from a Pod to the internet was painful. You had to use IP addresses, but cloud services (like AWS S3 or GitHub) constantly change their IPs! As of 2026, AWS introduced ApplicationNetworkPolicies specifically for EKS Auto Mode. This allows Layer 7 FQDN (Fully Qualified Domain Name) Egress Filtering.

• Instead of maintaining a list of 50 changing IP addresses, you simply write a policy that says: “This Pod is only allowed to talk to api.github.com and *.s3.amazonaws.com. Block everything else.”