Amazon EKS is described as "managed Kubernetes". Which parts of an EKS cluster does AWS actually run and bill you for, and which parts stay your responsibility?

## Two halves of any cluster Every Kubernetes cluster has a **control plane** — the API server that accepts manifests, the etcd key-value store that persists them, the scheduler that picks machines for pods, and the controller manager that reconciles the difference between desired and actual state — and a **data plane**, the machines that actually run the containers. Amazon EKS draws its managed line exactly there. AWS owns the control plane; you own the data plane and everything above the API. ## What AWS runs and you never touch When you create an EKS cluster, AWS provisions the control-plane components inside an AWS-owned account, spread over multiple Availability Zones in the Region, and operates them: capacity, patching, failure replacement and etcd backups are AWS's problem. You get an HTTPS API endpoint, which you can expose publicly, privately inside your VPC, or both. There is no control-plane instance in your account, no SSH, no flag you can hand-edit on the API server; configuration is limited to what the EKS API exposes. Control-plane logs are opt-in and delivered to CloudWatch Logs by type — `api`, `audit`, `authenticator`, `controllerManager`, `scheduler` — which is the only window you get into those processes. AWS also *publishes* things for the data plane: EKS-optimized AMIs, and EKS managed add-ons (the VPC CNI, `kube-proxy`, CoreDNS, the EBS CSI driver, the Pod Identity Agent). Publishing is not operating. You still choose when to move to a new add-on version, and a mismatch between add-on version and cluster version is a failure mode you own. ## What stays yours **Compute.** You choose how pods get a machine: *managed node groups* (AWS creates the Auto Scaling group and launch template and orchestrates a rolling AMI update when you ask for one), *self-managed nodes* (you own the ASG outright), *Fargate profiles* (no nodes at all — each pod gets its own AWS-managed micro-VM, billed per pod's requested vCPU and memory), or *Karpenter*, which watches for unschedulable pods and launches right-sized EC2 instances directly instead of scaling node groups. EKS Auto Mode, introduced in late 2024, hands most of that node lifecycle back to AWS at a premium. **Upgrades.** This is the responsibility candidates most often misplace. Upgrading is a sequence you drive: ```bash aws eks update-cluster-version --name prod --kubernetes-version 1.31 aws eks update-addon --cluster-name prod --addon-name vpc-cni --resolve-conflicts PRESERVE aws eks update-nodegroup-version --cluster-name prod --nodegroup-name app-nodes ``` Moving the control plane does not move your nodes; nodes keep their old kubelet version until you update them, within the version skew Kubernetes allows. Each minor version carries a standard-support window, after which the cluster is not force-upgraded — it rolls into extended support at a higher hourly rate. Upgrade cadence is therefore a standing operational commitment, not a one-time setup step. **Networking.** The VPC, subnets and security groups are yours. The Amazon VPC CNI gives every pod a real IP address from your subnets, so subnet CIDR sizing becomes a pod-capacity limit — an AWS-specific constraint with AWS-specific levers (prefix delegation, or custom networking onto a secondary CIDR range). **Access.** Mapping IAM principals to cluster permissions is yours too, done today through EKS *access entries* and AWS-managed access policies rather than by hand-editing the old `aws-auth` ConfigMap. ## What you are billed for Three buckets. First, the flat per-cluster hourly charge — it exists with zero pods running, which is the main economic argument against spinning up a cluster per team or per environment and the reason organisations consolidate into fewer, namespace-partitioned clusters. Second, the data plane: EC2 instances or Fargate pod resources. Third, everything around it that a cluster tends to create — EBS volumes, load balancers provisioned by controllers, NAT gateway data processing for egress, CloudWatch logs. ## Why interviewers ask this It is the cheapest possible test of whether "managed" means anything precise to you. A candidate who says "AWS runs Kubernetes for me" has not planned for node patching, add-on drift or the upgrade treadmill — the three things that actually consume a platform team's time on EKS.