Amazon EKS in Production: Control Plane, Compute, IAM, Networking, and Upgrades
What AWS manages in EKS, what remains in your account, and how node choices, VPC networking, identity, observability, availability, and cost interact.
Amazon Elastic Kubernetes Service operates a dedicated Kubernetes control plane for each cluster. AWS places API server and etcd capacity across Availability Zones and replaces failed control-plane instances. That removes control-plane installation and patching, not responsibility for workload configuration, access policy, network design, data protection, or most compute choices.
Compute models
Managed node groups automate EC2 provisioning and lifecycle through Auto Scaling groups. Self-managed nodes expose more control. Fargate supplies pod-oriented serverless compute. EKS Auto Mode and Karpenter can automate broader data-plane decisions. Each model changes patching, instance selection, daemon support, interruption handling, and cost; “managed” does not mean identical responsibility.
Identity and networking
AWS IAM authenticates access to EKS and grants workloads AWS API permissions through supported pod-identity mechanisms; Kubernetes RBAC still authorizes Kubernetes actions. Nodes and pods live in VPC networking governed by subnets, route tables, security groups, the VPC CNI, load balancers, and DNS. Plan IP capacity before scale creates an outage.
Upgrades, resilience, and observability
Control plane, nodes, add-ons, and application APIs have related but separate upgrade paths. Test version skew and deprecated APIs, then update nodes with disruption budgets and spare capacity. Spread workloads across zones, but remember that zonal EBS volumes constrain rescheduling. Collect control-plane logs, CloudWatch metrics, Kubernetes events, application telemetry, and node signals.
Cost and shared responsibility
Costs include the cluster control plane, EC2 or Fargate compute, EBS, load balancers, NAT, data transfer, logging, and add-ons. AWS secures and operates the managed service; customers still secure identities, workloads, images, secrets, network exposure, and timely node/add-on upgrades. Choose EKS when Kubernetes APIs and ecosystem portability justify that operational surface.
Sources: Amazon EKS architecture, EKS managed node groups, EKS IAM