Lesson 01 of 18 · Build
EKS architecture & mental model
Build the right mental model of Amazon EKS: what AWS runs for you, what you own, how the control plane reaches your VPC, the data-plane options, managed add-ons, and the version support calendar that drives your upgrade rhythm.
What AWS runs, what you run
EKS is managed Kubernetes: AWS runs the control plane (API servers and etcd across three availability zones, patched, scaled and backed up). You run everything else.
| AWS | You |
|---|---|
| API servers, etcd, scheduler, controller manager | Kubernetes version choice and upgrades (you trigger them) |
| Control-plane availability and scaling | Nodes: AMIs, patching, scaling |
| Integrations (IAM authentication, CloudWatch logging options) | Add-ons: VPC CNI, CoreDNS, kube-proxy, CSI drivers, controllers |
| Networking: VPC, subnets, IP planning, security groups | |
| Identity: who can access the cluster; pod IAM roles | |
| Workloads, policies, observability, backups |
EKS is like renting a flat where the landlord looks after the building: the roof, the lifts, the boiler (the control plane). You still choose your furniture, cook your food and lock your door (nodes, apps, security). And every year or so you must renew the lease (upgrade the Kubernetes version), or it gets expensive and eventually decided for you.
How the control plane reaches your nodes
The control plane lives in an AWS-managed VPC. EKS places network interfaces in your subnets so the API server can talk to kubelets (logs, exec, webhooks). The API endpoint can be:
| Endpoint access | Meaning |
|---|---|
| Public (optionally restricted to CIDRs) | kubectl from anywhere allowed; nodes reach it over the internet or via private access |
| Public + private | Nodes use the private endpoint inside the VPC; humans can use the public one |
| Private only | API reachable only from the VPC (or connected networks, VPN, bastion) |
Production clusters usually enable private access, and either disable public access or restrict it to known CIDRs.
Data-plane options
| Option | You manage | Good for |
|---|---|---|
| Managed node groups | Instance types, scaling ranges; AWS handles ASG and rolling updates | Predictable, simple node pools |
| Karpenter | NodePools and constraints; it launches and consolidates instances | Varied workloads, Spot, cost efficiency |
| Fargate | Nothing per node (one pod per micro-VM) | Small or isolated workloads; limits apply (no DaemonSets, no GPUs) |
| Self-managed nodes | Everything | Special AMIs or requirements |
| EKS Auto Mode | Less: AWS manages nodes and core add-ons too | Teams wanting maximum managed operations |
Many platforms combine a small managed node group (for system components, and Karpenter itself) with Karpenter for workloads.
Add-ons
Core components are installed as EKS add-ons (managed versions you can pin and upgrade through the API or Terraform): VPC CNI, CoreDNS, kube-proxy, EBS CSI driver, EKS Pod Identity Agent, and others. Everything else (AWS Load Balancer Controller, Karpenter, cert-manager, External Secrets…) you install with Helm or GitOps.
The support calendar
Each Kubernetes version gets standard support on EKS for roughly 14 months, then extended support for about another 12 months at an extra hourly cost per cluster, after which EKS upgrades it for you. Plan to upgrade every ~4–6 months (one minor at a time, lesson 09) so you're never forced.
Try it: explore a cluster (sandbox account)
You'll build the full stack with Terraform in the next lessons. For now, a quick look:
- Create a small cluster with
eksctl create cluster --name lab --nodes 2(a quick way to explore; delete it afterwards). aws eks describe-clusterfor version, endpoint access and the cluster security group.aws eks update-kubeconfig, thenkubectl get nodes -o wideandkubectl get pods -n kube-system. Which add-ons are running?- Find the ENIs EKS created in your subnets (
aws ec2 describe-network-interfaces --filters Name=description,Values='Amazon EKS*'). eksctl delete cluster --name labwhen done.
Going deeper: EKS design decisions
- Keep the control plane private; give humans access through SSO + access entries (lesson 05), and CI through OIDC roles.
- Put system add-ons on a small, stable node pool with taints, so workload scaling and Spot interruptions never disturb them.
- Turn on control-plane logging (audit, authenticator) to CloudWatch for security investigations, and decide retention deliberately.
- Treat clusters as cattle: everything from code (Terraform + GitOps), so a new cluster is minutes of automation, not days of clicking.
Recap
- AWS runs the control plane; you own nodes, add-ons, networking, identity, workloads and upgrades.
- Endpoint access: prefer private, restrict public.
- Data plane: managed node groups, Karpenter, Fargate, self-managed, or Auto Mode.
- Follow the support calendar: upgrade regularly to avoid extended-support cost and forced upgrades.
This site is a public version of my personal engineering knowledge hub. It intentionally excludes confidential company information and internal operational details.