On this page
EKS (Elastic Kubernetes Service)
EKS is AWS's managed Kubernetes. AWS runs the control plane (API server, etcd, scheduler) across multiple AZs for you; you bring the worker compute and your Kubernetes manifests. Everything that speaks standard Kubernetes — kubectl, Helm, operators, GitOps tools — works unchanged.
The Mental Model
Think of EKS as "Kubernetes with the hard 20% outsourced." Upgrading etcd, securing the API server, and keeping the control plane highly available are AWS's problem. Your problems remain: node capacity, pod permissions, networking, logging, and deployments.
Three ways to run the actual workloads:
- Managed node groups — EC2 instances that EKS provisions and updates for you (rolling AMI updates included)
- Self-managed nodes — your own EC2/ASG; maximum control, maximum toil
- Fargate profiles — serverless pods; no nodes to manage at all, with some restrictions (no DaemonSets, no GPUs)
EKS vs ECS in One Paragraph
ECS is AWS-proprietary and simpler — IAM-native, deep CodeDeploy integration, less to learn. EKS is standard Kubernetes — portable, huge ecosystem, but you inherit Kubernetes' complexity (RBAC, add-ons, upgrades). The exam cue for EKS is usually "the team already uses Kubernetes" or "must remain portable across clouds."
Why It Matters for DOP-C02
Recent exams test EKS operational plumbing, not Kubernetes trivia:
- How pods get AWS permissions without static keys (IRSA / Pod Identity)
- How logs and metrics reach CloudWatch (Container Insights, Fluent Bit, control plane logging)
- How scaling actually works (HPA + metrics server, Cluster Autoscaler, Karpenter)
- How CI/CD deploys to a cluster (CodeBuild running kubectl/Helm against the API server)