EKS: control plane, node groups and add-ons

You learned Kubernetes concepts in the DevOps Foundation — pods, deployments, services, config, self-healing. EKS (Elastic Kubernetes Service) is AWS's managed Kubernetes: the same Kubernetes you know, with AWS running the hard part for you. This module assumes that Foundation knowledge and focuses on what is different and AWS-specific about running Kubernetes on EKS. This first lesson is EKS's architecture — the control plane, node groups, and add-ons — so the rest of the module has a foundation. (Concept-and-usage, as throughout; you would run these in your own account.)

What EKS manages for you

Running Kubernetes yourself means operating the control plane — the API server, scheduler, etcd (the cluster's database), controllers — which is genuinely hard: it must be highly available, secured, backed up, and upgraded. EKS runs the control plane for you. AWS provisions it across multiple Availability Zones, keeps it available, patches and secures it, and gives you an endpoint to talk to. You pay a flat hourly fee for the managed control plane and stop worrying about the hardest, most critical part of a cluster.

What you still own on EKS:

The worker nodes — the EC2 instances (or Fargate) that run your pods. You choose and manage these (though managed node groups help — below).
Your workloads — the deployments, services and config you apply, exactly as in the Foundation.
Cluster configuration — networking, add-ons, access, upgrades of the node side.

So EKS is a split: AWS manages the control plane; you manage the nodes and workloads. That split is the whole value proposition — the part most likely to page you at 3am (the control plane) is AWS's problem, and you focus on running your applications.

Nodes: managed node groups and Fargate

Your pods run on worker nodes, and on EKS you have a few ways to provide them:

Managed node groups — EKS provisions and manages a group of EC2 instances as nodes for you: it handles their creation, and makes updates and scaling easier (draining and replacing nodes on upgrade). This is the common choice — you still choose instance types and sizes (Graviton and Spot from the compute module apply here), but EKS automates much of the node lifecycle.
Self-managed nodes — you run the EC2 instances yourself for maximum control; more work, rarely needed.
Fargate — run pods with no nodes to manage at all, the serverless option (the compute module). You can run some or all workloads on Fargate profiles; AWS provides per-pod compute. Simpler, at a per-pod cost.

A common pattern combines them: managed node groups for the baseline (with Spot for cost on interruptible, replicated workloads — the compute module), and sometimes Fargate for specific workloads. The point is that node provisioning on EKS ranges from "AWS does most of it" (managed groups) to "AWS does all of it" (Fargate), and you choose based on control-versus-effort.

Add-ons: the pieces that make a cluster usable

A bare Kubernetes cluster needs several components to be genuinely usable, and on EKS these are add-ons — managed or installed components AWS integrates:

VPC CNI — the networking plugin that gives pods IP addresses from your VPC (the networking module). On EKS, pods get real VPC IPs, which integrates Kubernetes networking with AWS networking (security groups, VPC routing) — a distinctive EKS trait.
CoreDNS — in-cluster DNS so services resolve by name (the Foundation's service discovery).
kube-proxy — service networking on each node.
EBS/EFS CSI drivers — let pods use AWS storage (EBS volumes, EFS) for persistence.
The AWS Load Balancer Controller — creates AWS load balancers (ALB/NLB) from Kubernetes ingress/service definitions (the ingress lesson).
Cluster Autoscaler / Karpenter — add and remove nodes based on demand (the scaling lesson).

EKS provides many of these as managed add-ons it keeps updated, and you install others. The idea to hold: a usable EKS cluster is the managed control plane plus a set of add-ons that connect Kubernetes to AWS (networking, storage, load balancing, autoscaling). Knowing these exist explains how a Kubernetes cluster actually integrates with the AWS around it.

Talking to the cluster

You interact with EKS the same way as any Kubernetes cluster — with kubectl (the Foundation's debugging lesson) — after configuring access:

aws eks update-kubeconfig --name my-cluster --region eu-west-1   # point kubectl at the EKS cluster
kubectl get nodes                                                 # the managed nodes, Ready
kubectl get pods -A                                               # workloads, incl. the add-ons in kube-system

aws eks update-kubeconfig sets up your kubeconfig to talk to the cluster, using your AWS credentials (via SSO — the access lesson) for authentication, so AWS IAM controls who can access the cluster. From there, everything you learned in the Foundation — kubectl apply, get, describe, logs — works identically. EKS is real Kubernetes; what differs is that AWS runs the control plane, IAM governs access, and the cluster is wired into your VPC and AWS services through add-ons. The rest of this module builds on exactly that.

Check your work

EKS manages the control plane (API server, scheduler, etcd, controllers — HA across AZs, patched, secured) for a flat fee — the hardest, most critical part is AWS's problem. You manage the worker nodes, your workloads, and cluster config. Split: AWS = control plane; you = nodes + workloads.

Nodes: managed node groups (EKS provisions/updates/scales EC2 nodes — common; you pick types, apply Graviton/Spot), self-managed (max control, rarely needed), or Fargate (no nodes, per-pod, serverless). Common pattern: managed groups (with Spot) + sometimes Fargate.

Add-ons connect Kubernetes to AWS: VPC CNI (pods get real VPC IPs), CoreDNS (DNS), kube-proxy, EBS/EFS CSI (storage), AWS Load Balancer Controller (AWS LBs from ingress), Cluster Autoscaler/Karpenter (nodes on demand). A usable cluster = managed control plane + these add-ons.

Access: aws eks update-kubeconfig points kubectl at the cluster, authenticated via AWS IAM (so IAM governs cluster access); then all Foundation kubectl skills work identically. EKS is real Kubernetes; AWS runs the control plane, IAM governs access, add-ons wire it to the VPC/services.

Practice

Explain the split of responsibilities between AWS and you on EKS, and why the control-plane part is the valuable one to offload.
Compare managed node groups, self-managed nodes and Fargate for providing worker capacity.
Explain what the VPC CNI does and why pods getting real VPC IPs matters for AWS integration.
List four EKS add-ons and what each provides.
Explain how aws eks update-kubeconfig and IAM govern access to the cluster.
Explain how the compute module's Graviton and Spot advice applies to EKS node groups.

Official documentation

AWS — What is Amazon EKS? — The managed control plane and cluster architecture.
AWS — EKS nodes (managed node groups, Fargate) — Ways to provide worker capacity.
AWS — EKS add-ons — The components that make a cluster usable.

Next: deployments, services and config on EKS.