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.