Day 17: EKS Architecture

Phase 5 · Aug 28, 2026

Agenda (2–3 hours)

• Read (45 min): EKS architecture documentation; managed node groups; EKS add-ons (CoreDNS, kube-proxy, VPC CNI)
• Study (45 min): How does the EKS control plane differ from self-managed Kubernetes? What does AWS manage vs what do you manage?
• Practice (45 min): Create an EKS cluster with a managed node group; deploy a Deployment + Service; verify pod scheduling
• Challenge (30 min): Compare the blast radius of a node failure in EKS vs a Fargate task failure in ECS. Which is more operationally complex to recover from?

EKS Architecture

AWS Managed Control Plane (multi-AZ, auto-scaled)
├── kube-apiserver
├── etcd (managed, backed up by AWS)
├── kube-controller-manager
└── kube-scheduler

Your VPC
├── Managed Node Group (EC2 Auto Scaling Group)
│   ├── Node (Kubelet, kube-proxy, VPC CNI)
│   └── Node
└── Fargate Profile (optional: serverless pods)

AWS manages: control plane availability, etcd backups, API server scaling.
You manage: node group sizing, OS patching (or use managed nodes), add-ons.

VPC CNI

EKS VPC CNI assigns each pod a real VPC IP address (not a NAT overlay):

Node ENI (primary): 10.0.1.5
Node ENI (secondary): 10.0.1.6 → Pod A
                      10.0.1.7 → Pod B
                      10.0.1.8 → Pod C

Benefits:

• Pods routable from the VPC without NAT
• Security groups can be applied to pods directly (via SecurityGroupPolicy CRD)
• No network performance overhead from overlay network

Managed Add-ons

aws eks update-addon \
  --cluster-name my-cluster \
  --addon-name coredns \
  --resolve-conflicts OVERWRITE

Key Takeaways

• AWS manages the EKS control plane; you own node groups and add-ons
• VPC CNI gives each pod a real VPC IP — security groups and routing work natively
• Managed node groups handle OS patching and graceful draining during upgrades
• EKS is more flexible than ECS but carries more operational surface area

Tomorrow: service discovery — AWS Cloud Map, Route 53, and Envoy sidecar patterns.