How does EKS differ from self-managed Kubernetes?

Understanding the difference between EKS and self-managed Kubernetes requires knowing what the Kubernetes control plane actually does and why managing it yourself is an operational burden that most teams underestimate.

Kubernetes has two layers: the control plane and the data plane. The control plane is the brain — it consists of the API server (receives all requests), etcd (the distributed key-value store holding all cluster state), the scheduler (decides which node runs each pod), and the controller manager (ensures desired state matches actual state). The data plane is the muscle — the worker nodes running kubelet, kube-proxy, and your actual application containers.

With self-managed Kubernetes, you own everything. You must install kubeadm or use a tool like kops to bootstrap the cluster. You manage etcd yourself — this means configuring it as a 3 or 5 node cluster for quorum, managing backups, handling disk pressure, and performing version upgrades that require careful rolling restarts. etcd is the single most critical component: if etcd loses data, your cluster state is gone. You must also handle API server high availability by running multiple replicas behind a load balancer, manage TLS certificates for all component-to-component communication (API server to kubelet, kubelet to API server, etcd peer communication), and handle Kubernetes version upgrades which require upgrading the control plane first, then worker nodes, with careful attention to version skew policies.

With EKS, AWS manages the entire control plane. The API server runs across at least three Availability Zones with automatic failover. etcd is managed, backed up, and encrypted by AWS. You never SSH into a control plane node — you cannot even see them. AWS handles Kubernetes version upgrades for the control plane (you trigger the upgrade, AWS performs the rolling update). The API server endpoint can be configured as public (accessible from the internet), private (accessible only within the VPC), or both. EKS also integrates natively with AWS services: IAM Roles for Service Accounts (IRSA) maps Kubernetes service accounts to IAM roles, the AWS Load Balancer Controller provisions ALBs and NLBs from Kubernetes Ingress resources, EBS CSI driver manages persistent volumes, and CloudWatch Container Insights provides monitoring.

However, EKS is not fully managed — you still manage worker nodes. You have three options: self-managed node groups (full EC2 control, you handle AMI updates and scaling), managed node groups (AWS handles node provisioning and lifecycle, you choose instance types), and Fargate profiles (fully serverless, AWS manages the underlying compute — no nodes to manage at all). Each option trades control for operational simplicity.

The cost comparison is nuanced. EKS charges $0.10 per hour ($73/month) for the control plane. Self-managed Kubernetes has no such fee, but you pay for the EC2 instances running control plane components, plus the engineering time to maintain them. For most organizations, the control plane management fee is trivial compared to the operational cost of maintaining etcd, handling certificate rotation, and performing safe upgrades. A single botched etcd backup or failed upgrade can cost days of downtime.

Production gotchas with EKS include: the API server has rate limits (you can hit throttling with large clusters), Kubernetes version support has a lifecycle (EKS supports four minor versions, and you must upgrade before end-of-support or AWS will auto-upgrade), and the VPC CNI plugin uses one ENI per pod by default, which limits pod density based on instance type ENI limits (a t3.medium supports only 17 pods). Self-managed Kubernetes avoids the CNI pod density issue since you can choose Calico or Cilium with overlay networking, but introduces its own networking complexity.

The decision framework: choose EKS if you want to focus on application delivery rather than infrastructure. Choose self-managed if you need full control over the control plane (rare), have a dedicated platform engineering team, or have compliance requirements that demand you manage every component.