Managed Kubernetes (EKS/GKE/AKS) vs. self-hosted (kubeadm) — what are the tradeoffs?

What "managed" actually takes off your plate

With EKS, GKE, or AKS, the cloud provider operates the entire control plane (see the fundamentals topic) on your behalf: etcd's availability and backups, the API server's uptime and patching, the scheduler and controller manager's operation — you interact with the API server endpoint, but never directly manage or even see these components. This removes precisely the operational burden covered in the etcd-backup and cluster-upgrade questions — a managed cluster's provider is contractually responsible for control-plane availability and (typically) for keeping it patched against known vulnerabilities.

Managed (EKS/GKE/AKS):
  Control plane -> operated by the cloud provider (etcd, API server, scheduler, all managed)
  Worker nodes  -> you still manage (though node-pool auto-upgrade features often help)

Self-hosted (kubeadm):
  Control plane -> YOU stand up, secure, back up, upgrade, and keep highly available
  Worker nodes  -> YOU manage entirely

What you still own, even on a managed offering

Worker nodes (or their underlying VM images, if not using a fully serverless node offering), application-level RBAC/security configuration, NetworkPolicy design, resource requests/limits tuning, and everything at the application/workload layer remain your responsibility regardless of whether the control plane is managed — "managed Kubernetes" specifically means the control plane is handled for you, not that all operational responsibility disappears.

The case for managed Kubernetes

• Removes the hardest, highest-stakes operational burden — etcd disaster recovery and control-plane high availability are genuinely difficult to get right, and getting them wrong has severe consequences (see the etcd question); letting a cloud provider with deep operational expertise and scale handle this is a strong default for most organizations.
• Faster time to a working, reasonably secure cluster — spinning up a managed cluster takes minutes; building a properly secured, highly-available self-hosted control plane from scratch is a substantial undertaking even for an experienced platform team.
• Integrated with the cloud provider's broader ecosystem — IAM integration, load balancer provisioning, storage classes backed by the provider's native storage, all typically pre-wired and well-supported.

The case for self-hosting

• Full control over every component's configuration — useful for specialized requirements a managed offering's defaults don't accommodate, or for genuinely needing a specific Kubernetes version/feature-gate combination a managed provider hasn't yet made available.
• Can run anywhere — on-premises data centers, air-gapped environments with no cloud connectivity, or genuinely multi-cloud/hybrid setups where no single cloud provider's managed offering covers every environment.
• No managed-service fee — though this needs to be weighed honestly against the real (often underestimated) engineering time cost of operating the control plane yourselves — the "savings" can easily be smaller than the labor cost of the operational burden taken on.
• Deeper organizational Kubernetes expertise as a side effect — some organizations deliberately self-host specifically to build this expertise in-house, though this is a real strategic choice with real cost, not a free byproduct.

Practical guidance for most organizations

For the large majority of teams, managed Kubernetes is the sound default specifically because control-plane operation (etcd, API server HA, security patching) is genuinely hard to do well and has severe failure consequences if done poorly — self-hosting is usually justified only by a specific, concrete requirement (air-gapped/on-prem deployment, a strategic need for deep in-house expertise, cost at a scale where the managed-service fee is truly significant relative to engineering cost) rather than as a default choice made for its own sake.

A candidate who can name specifically which operational burdens shift to the provider (etcd, control-plane HA/patching) versus what remains the team's responsibility regardless (worker nodes, application-layer configuration) demonstrates real understanding of the tradeoff, rather than a vague sense that "managed is easier."