Managed vs Self-Managed Kubernetes in AWS

What the Kubernetes control plane actually is

Kubernetes has two distinct parts: the control plane and the data plane (worker nodes).

The control plane is the brain of the cluster. It consists of:

• kube-apiserver — the REST API that everything talks to (kubectl, controllers, kubelet on nodes)
• etcd — a distributed key-value store that holds the entire cluster state
• kube-scheduler — decides which node to place each pod on
• kube-controller-manager — runs control loops that reconcile desired state with actual state

For the control plane to be highly available, you need at least 3 etcd members (to maintain quorum), multiple API server instances, and load balancing in front of them. etcd requires consistent network latency and fast disks — it’s notoriously sensitive to I/O performance. A misconfigured or overloaded etcd cluster can bring down your entire Kubernetes cluster.

Running this yourself on EC2 is non-trivial. EKS replaces the entire control plane with a managed service and hides it from you. You never see the etcd instances, never configure the API server, and never deal with control plane upgrades manually.

EKS vs self-managed Kubernetes

What EKS still leaves to you

It’s important to be honest about what “managed” means with EKS. AWS manages the control plane — you manage everything else:

Worker nodes. EC2 instances in your node groups are your responsibility. You choose the instance type, configure the AMI, handle OS security patches (or use managed node groups to simplify this), and decide when to rotate nodes for kernel updates.

Networking. The VPC CNI plugin assigns pod IPs from your VPC subnets. You configure security groups, decide on subnet sizing, and configure egress. Getting this wrong causes IP exhaustion or connectivity failures.

Add-ons. CoreDNS, kube-proxy, the AWS Load Balancer Controller, the Cluster Autoscaler, and the EBS/EFS CSI drivers all need to be installed, configured, and kept up to date. EKS managed add-ons simplify some of this, but not all.

Node upgrades. EKS upgrades the control plane, but you upgrade node groups separately. Nodes running old Kubernetes versions will eventually go out of support.

Application manifests. Every deployment, service, ingress, config map, and RBAC policy is your responsibility.

EKS significantly reduces your operational burden, but it doesn’t eliminate it. Self-managed Kubernetes adds the control plane burden on top of everything above.

What self-managed Kubernetes actually requires

To run a production-grade self-managed Kubernetes cluster on EC2, you need to:

1. Bootstrap the cluster — use kubeadm, kops, or a tool like Rancher to initialize the control plane and join worker nodes. This requires understanding certificates, cluster configuration, and network plugin setup.

2. Design for HA — run at least 3 control plane nodes across multiple AZs, with an external load balancer in front of the API server. etcd should be on its own nodes with fast SSD-backed storage (io1/io2 EBS volumes).

3. Backup etcd — etcd is the single source of truth for your cluster. Without regular backups and a tested restore procedure, a failure can mean rebuilding the cluster from scratch.

4. Handle upgrades — Kubernetes releases a new minor version approximately every 4 months. Falling behind means running unsupported versions. Manual upgrades require careful sequencing: control plane first, then nodes, with version skew constraints between components.

5. Respond to control plane incidents — if your API server becomes unavailable at 2am, your team fixes it. There is no AWS support SLA covering your self-managed cluster.

The tools for self-managed Kubernetes on AWS:

• kubeadm — the standard tool for bootstrapping clusters manually
• kops — generates and manages Kubernetes clusters on EC2, handles control plane HA, has Terraform integration
• Rancher — a management platform that can provision and manage Kubernetes clusters on any infrastructure

The real TCO comparison

The common objection to EKS is the $0.10/hour control plane fee — $72/month. Teams sometimes want to avoid this by running Kubernetes themselves.

Here’s the actual comparison for a small cluster:

EKS control plane cost: $72/month.

Self-managed control plane cost on EC2:

• 3 × t3.medium control plane nodes: 3 × $0.0416/hr × 720 hours = ~$90/month
• 3 × 20GB io1 EBS volumes for etcd: ~$30/month
• Your time: let’s conservatively estimate 4 hours/month for patching, monitoring, and incident response at $100/hr engineer cost = $400/month

Total self-managed: ~$520/month to save $72/month on EKS.

The math doesn’t work. Self-managed Kubernetes on EC2 makes sense in a narrow set of scenarios:

• You have a strict compliance requirement that prohibits managed services
• You need a Kubernetes distribution with certifications EKS doesn’t provide
• You’re running in an air-gapped environment where EKS isn’t available

For everything else, EKS is the answer. See EKS overview for how to get started with a managed cluster.

When self-managed is genuinely justified

There are real reasons to run self-managed Kubernetes, though they’re uncommon:

Compliance and certification requirements. Some regulated industries require specific Kubernetes certifications (FIPS-validated builds, specific audit logging configurations) that EKS doesn’t support. If your compliance framework mandates something EKS can’t provide, self-managed is the path.

Air-gapped or on-premises environments. EKS is an AWS service. If you’re running in an environment without internet access or in an on-premises data center that also uses Kubernetes (for consistency), self-managed is your only option on-prem. EKS Anywhere extends EKS to on-premises, which is often a better choice than raw self-managed.

Extreme customization. If you need to modify kube-scheduler behavior, run custom API server flags not exposed by EKS, or use a Kubernetes fork with proprietary patches, self-managed gives you that control.

Very large clusters where the control plane SLA isn’t sufficient. At extreme scale, some teams run their own control plane to have full visibility and control over etcd performance.

For most teams, none of these apply. Use EKS.