Module 06 — Managing Networking in Amazon EKS

TOPIC 1 AWS networking fundamentals

EKS clusters live inside an Amazon VPC (Virtual Private Cloud). Understanding VPC building blocks — subnets, route tables, security groups, and internet/NAT gateways — is essential before diving into EKS-specific networking.

Core VPC components

VPC — isolated virtual network, defined by a CIDR block
Public subnet — has route to Internet Gateway; resources get public IPs
Private subnet — no direct internet route; uses NAT Gateway for outbound
Route table — controls where subnet traffic is directed
Internet Gateway (IGW) — allows inbound internet traffic to public subnets
NAT Gateway — allows private subnet outbound internet (no inbound)

Security controls

Security groups — stateful, instance-level firewall (allow rules only)
NACLs — stateless, subnet-level rules (allow + deny)
ENI — Elastic Network Interface; virtual NIC attached to an instance
VPC Peering — connects two VPCs; traffic stays on AWS backbone
EKS nodes and pods reside in subnets within your VPC

What is the difference between a public and private subnet in AWS?

A public subnet has a route to an Internet Gateway (IGW), so resources can receive inbound traffic from the internet. A private subnet has no such route — outbound internet access uses a NAT Gateway, but no inbound connections are possible directly.

What makes security groups "stateful"?

Stateful means return traffic is automatically allowed. If you allow inbound HTTP (port 80), the response traffic is permitted without an explicit outbound rule. NACLs, by contrast, are stateless — you must explicitly allow both directions.

What is an ENI and why does it matter for EKS?

An Elastic Network Interface (ENI) is a virtual network card you can attach to EC2 instances. In EKS, the VPC CNI plugin assigns secondary IP addresses from ENIs attached to nodes — giving each pod its own real VPC IP without needing an overlay network.

TOPIC 2 EKS communication types

EKS has three distinct pod communication paths, each using a different mechanism. Understanding which mechanism handles which path is a core exam topic.

Communication type	Scope	Mechanism
Container-to-container	Within the same Pod	Shared network namespace — containers use `localhost`
Pod-to-pod (intrahost)	Same node, different Pods	Linux Virtual Ethernet Device (veth) pairs — connected through the node's network bridge
Pod-to-pod (interhost)	Different nodes	Amazon VPC CNI plugin — pods get real VPC IPs, traffic routes natively through VPC
External-to-cluster	Internet or VPC to cluster	LoadBalancer service (NLB/ALB provisioned by AWS)

How do two containers in the same pod communicate?

Containers in the same pod share a network namespace. They see the same network interfaces and communicate over localhost (127.0.0.1). Port conflicts between containers in the same pod are possible — each must use a unique port.

What mechanism handles pod-to-pod traffic on the same node (intrahost)?

Linux Virtual Ethernet Device (veth) pairs. Each pod gets a veth pair — one end in the pod's network namespace, the other in the host namespace. The host's Linux bridge connects veth pairs so pods on the same node can reach each other directly.

What mechanism handles pod-to-pod traffic across different nodes (interhost)?

Amazon VPC CNI plugin. Because each pod gets a real VPC IP address (not an overlay address), pods on different nodes communicate directly via standard VPC routing — no encapsulation or tunnelling required. The VPC subnet's route table handles it natively.

How does external traffic reach a workload inside an EKS cluster?

Via a LoadBalancer service — which provisions an AWS NLB or ALB. The load balancer sits outside the cluster, receives external traffic, and forwards it to the correct node/pod. NodePort and Ingress are alternatives for different use cases.

TOPIC 3 Amazon VPC CNI plugin

The Amazon VPC CNI plugin is the default CNI for EKS. It fundamentally differs from overlay-based CNIs: pods get real VPC IP addresses — no encapsulation, no tunnel, native VPC routing. This is the key idea for the exam.

Animation · Amazon VPC CNI — pods get real VPC IPs

What is the core difference VPC CNI brings vs a traditional overlay CNI?

With VPC CNI, each pod gets an IP address directly from the VPC CIDR — the same IP is visible both inside the pod and on the VPC network. Traditional overlay CNIs (Calico, Flannel) give pods overlay IPs and encapsulate traffic, adding overhead. VPC CNI requires no encapsulation.

How does the VPC CNI plugin assign IP addresses to pods?

The VPC CNI attaches secondary ENIs to the EC2 node and pre-warms a pool of secondary IP addresses from the VPC subnet. When a pod is scheduled, the CNI assigns one of these pre-allocated IPs to the pod's veth interface — startup is fast because IPs are already reserved.

What limits the number of pods a node can run in EKS with VPC CNI?

The maximum number of ENIs and secondary IPs the EC2 instance type supports. Larger instances (e.g. m5.large vs m5.xlarge) support more ENIs and more secondary IPs, thus more pods. This is an important sizing constraint when choosing instance types for EKS node groups.

What is "IP mode" vs "instance mode" in the context of the VPC CNI?

Instance mode: the load balancer (NLB) sends traffic to the node's port; kube-proxy then routes it to the pod. IP mode: the NLB sends traffic directly to the pod IP, bypassing kube-proxy entirely. IP mode requires the VPC CNI and reduces latency.

TOPIC 4 Network Policies

By default, all pods in a cluster can communicate with all other pods. NetworkPolicy resources let you enforce pod-level firewall rules — controlling which pods can talk to which. The default-deny pattern is a security best practice.

Animation · NetworkPolicy — from open to locked-down to selective allow

Default deny all (namespace-wide)

kind: NetworkPolicy
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

Allow nginx → webapp only

spec:
  podSelector:
    matchLabels:
      app: webapp
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: nginx

What is the default network behaviour in a Kubernetes cluster with no NetworkPolicies?

All pods can communicate with all other pods in any namespace, and all pods can initiate external connections. There is no built-in isolation — you must explicitly create NetworkPolicy resources to restrict traffic.

What does a NetworkPolicy with an empty podSelector ({}) select?

An empty podSelector: {} matches ALL pods in the namespace. Combined with policyTypes: [Ingress, Egress] and no rules, this creates a default deny all policy — blocking all inbound and outbound traffic for every pod in the namespace.

Do NetworkPolicies apply to pods across namespaces?

NetworkPolicies are namespace-scoped. A policy in namespace A only affects pods in namespace A. To allow cross-namespace traffic, use a namespaceSelector in the ingress/egress rules. Without it, only pods within the same namespace are matched.

Does EKS enforce NetworkPolicies by default?

NetworkPolicy enforcement depends on the CNI plugin, not Kubernetes itself. The Amazon VPC CNI supports NetworkPolicy enforcement through the Network Policy Controller add-on. Without a CNI that supports it, NetworkPolicy objects are accepted by the API server but have no effect.

NetworkPolicies operate at which layer — pod, node, or namespace?

Pod level. NetworkPolicies select pods using label selectors and control traffic to/from those specific pods. They are namespace-scoped objects but apply at the individual pod (IP/port) level — not at the node or subnet level. Security groups operate at a higher (node/ENI) level.

TOPIC 5 Security groups for pods

Beyond NetworkPolicies, EKS supports assigning AWS security groups directly to pods. This lets you apply VPC-level firewall rules (security groups) to individual pods rather than to entire nodes — useful when pods need access to AWS services like RDS or ElastiCache.

What problem does "security groups for pods" solve?

Without this feature, all pods on a node share the node's security group. You cannot restrict which pods can reach an RDS database at the SG level. Security groups for pods assign an AWS SG to a specific pod, enabling precise VPC-level access control (e.g. only the api pod can reach the RDS SG).

How are security groups assigned to pods in EKS?

Using a custom EKS CRD called SecurityGroupPolicy. You define a SecurityGroupPolicy resource specifying a podSelector (or serviceAccountSelector) and the security group IDs to assign. The VPC CNI plugin then attaches a branch ENI with those SGs to matching pods.

What is the key difference between NetworkPolicy and security groups for pods?

NetworkPolicy is a Kubernetes-native, CNI-enforced control for pod-to-pod traffic using label selectors. Security groups for pods are AWS-native VPC controls that apply to pod ENIs — useful for controlling access to AWS services (RDS, ElastiCache) and enforcing VPC-level rules alongside K8s-level policies.

TOPIC 6 Kubernetes Service types

A Service is the stable endpoint for a set of pods — it abstracts away pod IP churn. Kubernetes defines four service types, each for a different exposure scope. Know all four for the exam, especially what each wraps and what AWS resource it provisions.

Animation · Four Service types and their traffic flow

TYPE 1

ClusterIP

Default. Internal only — not reachable from outside the cluster.

TYPE 2

NodePort

Exposes on a static port (30000–32767) on every node IP. Wraps ClusterIP.

TYPE 3

LoadBalancer

Provisions AWS NLB/ALB. Internet-accessible. Wraps NodePort.

TYPE 4

ExternalName

Maps to an external DNS name via CNAME. No proxying.

Type	Scope	AWS resource	When to use
ClusterIP	Cluster-internal only	None	Internal microservice communication; backend APIs
NodePort	External via node IP + port	None (uses EC2 node ports)	Dev/test external access; custom load balancer in front
LoadBalancer	External via AWS LB	NLB or ALB (annotation-driven)	Production external services; single service exposure
ExternalName	External DNS resolution	None (CNAME record)	Map Kubernetes service name to external DB/API endpoint

What is a ClusterIP service and who can reach it?

ClusterIP is the default service type. It assigns a stable virtual IP address reachable only from within the cluster. Pods use this IP (or the service DNS name) to reach other pods. External clients cannot reach a ClusterIP service — it is completely internal.

What port range does NodePort use and how does traffic flow?

NodePort allocates a port in the range 30000–32767 on every node. External clients send traffic to <NodeIP>:<NodePort>; kube-proxy on the node forwards it to the ClusterIP, which routes to a pod. NodePort wraps ClusterIP — a ClusterIP is created automatically.

What does a LoadBalancer service provision in AWS?

A LoadBalancer service automatically provisions an AWS Network Load Balancer (NLB) by default, or an ALB if the AWS Load Balancer Controller is installed and annotated. It wraps NodePort — traffic hits the LB, goes to a node port, and kube-proxy routes it to a pod. Annotation: service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: instance

How does ExternalName differ from all other service types?

ExternalName creates a CNAME DNS record that maps the service name to an external DNS hostname (e.g. my.db.example.com). There is no proxying, no ClusterIP, and no kube-proxy involvement. It lets pods use a Kubernetes service name while the actual endpoint lives outside the cluster.

What is the nesting hierarchy of service types?

LoadBalancer wraps NodePort, which wraps ClusterIP. Creating a LoadBalancer service automatically creates a NodePort and a ClusterIP. Traffic path: Internet → AWS LB → Node:NodePort → kube-proxy → ClusterIP → Pod. ExternalName is separate — no ClusterIP, just a DNS CNAME.

What is the difference between LoadBalancer instance mode and IP mode?

Instance mode: NLB routes traffic to the EC2 node's port; kube-proxy routes to the pod. IP mode: NLB routes directly to the pod IP — kube-proxy is bypassed. IP mode requires VPC CNI (pods need real VPC IPs). IP mode reduces hops and latency.

TOPIC 7 AWS Load Balancer Controller

The AWS Load Balancer Controller (AWS LBC) is a Kubernetes controller that provisions and manages ALBs for Ingress resources and NLBs for LoadBalancer services. It replaces the older in-tree cloud provider logic with a richer, annotation-driven model.

What AWS LBC manages

ALB — created for Ingress resources
NLB — created for LoadBalancer services
Annotation-driven configuration (no separate AWS console work)
Supports both instance mode and IP mode targets
Supports HTTP/HTTPS, SSL termination, and WAF integration

Key annotations

kubernetes.io/ingress.class: alb — tells LBC to handle this Ingress
ingressClassName: alb — newer IngressClass approach
service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: instance — NLB instance mode
service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip — NLB IP mode

What does the AWS Load Balancer Controller provision for an Ingress resource?

An Application Load Balancer (ALB). When you create an Ingress with ingressClassName: alb, the AWS LBC creates an ALB with listener rules matching the Ingress path/host rules. Each backend service becomes a target group on the ALB.

What annotation triggers the AWS LBC to manage a LoadBalancer service with an NLB?

service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: instance (or ip). The presence of the AWS LBC in the cluster and this annotation causes it to provision an NLB instead of using the in-tree ELB provisioner. The ip value enables direct pod IP targeting.

Why would you install the AWS Load Balancer Controller instead of relying on the built-in cloud provider?

The built-in in-tree cloud provider only supports Classic ELBs and basic NLBs. AWS LBC gives you: ALB support for Ingress, IP mode targets (pod-level routing), WAF integration, SSL policies, HTTP/2, path-based routing, multiple certificates, and faster feature updates from AWS.

TOPIC 8 Ingress & path routing

Ingress is a Kubernetes API object that provides a single entry point for multiple backend services using path-based or host-based routing. It is not a service type — it requires an Ingress Controller (e.g. AWS LBC) to function.

What is the main advantage of Ingress over multiple LoadBalancer services?

A single Ingress (one ALB) can route to multiple backend services based on URL path or hostname — instead of provisioning one NLB per service. Example: /webapp1 → webapp1:32003, /webapp2 → webapp2:32004. This saves cost and reduces complexity.

Does Ingress work without an Ingress Controller?

No. An Ingress object alone does nothing — it is just a configuration spec. An Ingress Controller watches for Ingress objects and configures the actual load balancer. In EKS, the AWS Load Balancer Controller is the standard Ingress Controller and creates an ALB.

How do you tell Kubernetes which Ingress Controller should handle an Ingress object?

Set spec.ingressClassName: alb in the Ingress manifest (or the older annotation kubernetes.io/ingress.class: "alb"). This tells the AWS Load Balancer Controller to claim and act on this Ingress, creating a corresponding ALB with matching listener rules.

What type of routing does Ingress support?

Two types: Path-based routing — route based on URL path prefix (e.g. /api → api-service). Host-based routing — route based on HTTP Host header (e.g. api.example.com → api-service, app.example.com → frontend-service). Both can be combined in one Ingress.

TOPIC 9 DNS resolution in EKS

DNS resolution in EKS works in three layers, each handling a different scope. Understanding which resolver handles which domain is important for debugging connectivity issues and for the exam.

Animation · Three-layer DNS resolution in EKS

Layer	Resolver	Handles	Example query
1	CoreDNS (EKS add-on)	Resources within the EKS cluster	`backend.prod.svc.cluster.local`
2	Default Route 53 Resolver	Resources within the VPC outside the cluster	RDS endpoint, internal EC2 hostname
3	Upstream DNS server	Resources outside the VPC	`api.stripe.com`, any public hostname

What is CoreDNS and what does it resolve?

CoreDNS is the cluster DNS add-on that runs as a Deployment in the kube-system namespace. It resolves Kubernetes internal names: services (svc.cluster.local), pods, and namespaced resources. It is the first DNS resolver a pod hits for any query.

What is the DNS format for a Kubernetes service?

Full form: <service-name>.<namespace>.svc.cluster.local. Within the same namespace, pods can use just <service-name>. CoreDNS appends the search domain. Example: backend (same namespace) or backend.prod.svc.cluster.local (cross-namespace).

A pod queries an RDS endpoint. Which DNS layer resolves it?

Layer 2 — Route 53 VPC Resolver. CoreDNS (layer 1) forwards queries it cannot resolve to the VPC's default DNS resolver (169.254.169.253). RDS endpoints are VPC-local DNS names that Route 53 resolves within the VPC. They don't need an upstream public DNS server.

How does CoreDNS know when to forward a query to the Route 53 resolver?

CoreDNS has a forward plugin in its ConfigMap. Any query that doesn't match cluster.local or other cluster domains is forwarded to the upstream resolver — which is the VPC's DNS server at the VPC base address +2 (e.g. 10.0.0.2). That resolver then either answers (VPC resource) or recurses to the internet.

TOPIC 10 Knowledge checks (from the course)

Official course knowledge-check questions formatted as flashcards. Try to answer before flipping.

KC1 — Which service type can be accessed from outside the cluster?
A. ClusterIP B. ExternalName C. NodePort only D. Both NodePort and LoadBalancer

✓ D — Both NodePort and LoadBalancer

NodePort exposes the service on a static port on every node IP (external access via NodeIP:NodePort). LoadBalancer additionally provisions an AWS LB. ClusterIP (A) is internal only. ExternalName (B) maps to external DNS but is not itself externally accessible.

KC2 — What is the Amazon VPC CNI plugin?
A. A security tool for pods B. A monitoring agent C. A routing overlay D. Plugin allowing pods to have the same IP inside the pod as on the VPC network

✓ D — Plugin allowing pods to have same IP inside the pod as on the VPC network

This eliminates the need for an overlay network. Pods get IPs from the VPC CIDR — the pod IP is the same address visible to other VPC resources. Option C (routing overlay) is the opposite of what VPC CNI does.

Traffic routing activity — Intranode pod-to-pod uses what mechanism?

Linux Virtual Ethernet Device (veth) pairs. Each pod on the node has a veth pair — one end in the pod namespace, the other in the host namespace. Intra-node pods communicate via the host network bridge connecting all veth pairs on that node.

Traffic routing activity — Internode pod-to-pod (different nodes) uses what?

Amazon VPC CNI plugin. Because each pod has a real VPC IP, the VPC routing table routes packets directly between pods on different nodes — no tunnel or encapsulation. This is the key differentiator of VPC CNI versus overlay-based CNIs.

Traffic routing activity — External traffic to a service uses what?

LoadBalancer service. An AWS NLB or ALB is provisioned by the service controller (or AWS LBC). External clients connect to the load balancer's public endpoint; the LB forwards traffic to the appropriate node port or pod IP.

Which Ingress Controller does the AWS Load Balancer Controller create — NLB or ALB?

ALB for Ingress resources, NLB for LoadBalancer services. The AWS LBC handles both. An Ingress with ingressClassName: alb creates an Application Load Balancer (Layer 7, HTTP/HTTPS). A LoadBalancer service with the NLB annotation creates a Network Load Balancer (Layer 4, TCP/UDP).

Name the three CoreDNS / DNS layers in EKS in order.

1. CoreDNS — resolves resources inside the EKS cluster (*.cluster.local)
2. Route 53 VPC Resolver — resolves resources inside the VPC (RDS endpoints, EC2 names)
3. Upstream DNS — resolves resources outside the VPC (public internet hostnames)

🌐 Module 06 — Managing Networking in Amazon EKS

What's in this module