Amazon EKS
Amazon EKS (Elastic Kubernetes Service) is managed Kubernetes on AWS. AWS runs the control plane across three Availability Zones and patches it; you bring your workloads and your worker nodes. Everything else is standard Kubernetes — the same kubectl, Helm, and ecosystem you already know, with AWS networking, load balancing, and IAM integrated cleanly.
Launched in 2018, EKS is the right choice when your team already runs Kubernetes, needs a specific Kubernetes feature, or wants to keep the platform portable across clouds.
Architecture
A Kubernetes cluster has two layers. AWS runs the control plane — API server, scheduler, controllers, and etcd — spread across three AZs, patched and backed up for you; you only see the API endpoint. You own the data plane: the worker nodes where pods actually run.
worker nodeworker node
Fargate podsNode Options
There are three ways to provide nodes. Self-managed nodes are your own EC2 instances joined to the cluster — most control, most work, rarely chosen today. Managed node groups let EKS provision, patch, and roll EC2 nodes you size — the common starting point. Fargate profiles run pods with no nodes at all, ideal for small or bursty workloads.
Many clusters add Karpenter, an open-source autoscaler that picks the right instance type for unscheduled pods in real time. It scales faster than the older Cluster Autoscaler and packs nodes better, usually cutting cost.
Networking and IAM
EKS uses the VPC CNI by default, so every pod gets a real private IP from your VPC — fast and simple, but pods consume VPC addresses, so size subnets generously. The AWS Load Balancer Controller turns a Kubernetes Ingress into an ALB and a LoadBalancer Service into an NLB.
For pod permissions, map a Kubernetes service account to an IAM role with IRSA or the newer, simpler EKS Pod Identity. Both give each workload short-lived, least-privilege AWS credentials — never store long-lived keys in a pod.
Pricing
EKS bills a fixed control-plane fee of about USD 0.10 per hour (~USD 73 per month) per cluster, regardless of size, plus standard EC2 or Fargate cost for the data plane. That fixed floor makes a tiny EKS cluster relatively expensive — for small workloads, ECS, which has no control-plane fee, is usually cheaper.
Keep EKS cost reasonable with Karpenter or Cluster Autoscaler, Spot capacity in node groups, a Fargate profile for short-lived pods, and account-wide Savings Plans covering both EC2 and Fargate.
EKS — managed Kubernetes — choose it for the Kubernetes API, ecosystem, and cross-cloud portability, and when the team already has the skills.
ECS — AWS-native and simpler, with no control-plane fee. Choose it when you do not specifically need Kubernetes, especially for small workloads.
- Adopting EKS without Kubernetes experience — the learning curve is real, and ECS is simpler if you have none.
- Running a tiny workload on EKS and wasting the ~USD 73/month control-plane fee — use ECS for small projects.
- Undersizing VPC subnets — the VPC CNI assigns each pod a real VPC IP, so small subnets exhaust addresses and pods fail to schedule.
- Storing long-lived AWS access keys inside pods instead of using IRSA or Pod Identity.
- Skipping Kubernetes versions during upgrades — EKS does not support jumping versions; upgrade one minor version at a time.
- Hand-writing access tokens instead of managing cluster access through IAM Identity Center or
aws eks update-kubeconfig.
- Start with managed node groups; move to self-managed only for genuine full-control needs.
- Give pods AWS permissions through IRSA or EKS Pod Identity — never embed access keys.
- Plan VPC IP space generously, since every pod consumes a real VPC address.
- Use Karpenter for autoscaling — faster and better bin-packing than the Cluster Autoscaler.
- Expose services with the AWS Load Balancer Controller rather than hand-built load balancers.
- Upgrade Kubernetes one minor version at a time and pin add-on versions.
Knowledge Check
In EKS, who is responsible for the Kubernetes control plane versus the data plane?
- AWS runs and patches the control plane across three AZs; you manage the data plane (worker nodes)
- You provision and patch both the control plane and the data plane yourself across every availability zone in the region
- AWS runs both the control plane and the worker nodes; you only submit YAML manifests
- You host the control plane on your own instances while AWS runs and scales the worker nodes
Why must VPC subnets be sized generously for an EKS cluster using the default VPC CNI?
- Every pod gets a real private IP from the VPC, so small subnets exhaust addresses and pods fail to schedule
- The managed control plane reserves a full half of every subnet's addresses for its own internal networking components
- Each worker node requires its own dedicated /24 subnet that no other node may share
- Load balancers consume one private IP for every request they forward into the cluster
A team is launching a small, low-traffic service and has no Kubernetes experience. What is the better fit?
- ECS — it is simpler and has no control-plane fee, which EKS charges (~USD 73/month) regardless of size
- EKS with a Fargate profile — Kubernetes is always the safer long-term choice
- EKS with self-managed nodes — running and hand-patching your own EC2 node group gives the most control over every individual host
- EKS — the control-plane fee is waived for small, low-traffic clusters below a usage threshold
What is the recommended way to give an EKS pod permission to call AWS APIs?
- Map its service account to an IAM role with IRSA or EKS Pod Identity for short-lived, least-privilege credentials
- Store a long-lived IAM access key and secret in the pod's environment variables for the container to read at startup time
- Give every node a broad shared instance role that all pods on that node inherit at once
- Embed the credentials directly in the container image so they ship with every deployment
You got correct