---
title: "How Amazon EKS works"
chapter: "02"
---

# How Amazon EKS works

An EKS cluster has an AWS-managed Kubernetes **control plane** and customer
workloads running on worker compute.

## The two halves

The control plane contains Kubernetes API servers and the cluster state store.
AWS runs this across multiple Availability Zones. You pay a per-cluster fee and
choose a supported Kubernetes version.

Worker compute can be EKS Auto Mode managed instances, EC2 managed node groups,
AWS Fargate, or self-managed EC2. Kubernetes schedules Pods onto suitable
capacity.

## Shared responsibility in one sentence

AWS operates the EKS service and control-plane infrastructure; you own access,
workload code and images, data, configuration, availability choices, and
incident response. Your node responsibility changes with the compute model.

## AWS building blocks around EKS

- VPC, subnets, route tables, security groups, endpoints, NAT, and DNS.
- IAM, EKS access entries, Kubernetes RBAC, and EKS Pod Identity.
- ECR, Inspector, KMS, Secrets Manager, GuardDuty, and CloudTrail.
- ALB/NLB, Route 53, CloudFront, WAF, and ACM.
- EBS, EFS, FSx, RDS/Aurora, DynamoDB, and ElastiCache.
- CloudWatch, ADOT, Amazon Managed Service for Prometheus, and Grafana.

## One cluster or many?

Use business and security boundaries—not fashion. Separate clusters when a
failure, trust boundary, region, lifecycle, or team autonomy requires it. Every
extra cluster adds upgrades, add-ons, policy, delivery, and observability work.

## Feynman check

EKS removes the job of building and repairing the Kubernetes control plane. It
does not remove application architecture or platform engineering.