"Just use managed Kubernetes" is the right advice for most teams and dangerously incomplete for the rest. "Self-hosted" also hides a spectrum, from a hand-rolled kubeadm cluster to a fleet driven by Cluster API. This is the honest side-by-side: who owns the control plane, what each option truly costs once you price in engineering time, and the specific reasons that justify running Kubernetes yourself.
Key takeaways
- The control plane is the whole argument — managed vs self-hosted is really a question of who owns the API server, etcd, and their blast radius.
- "Free" self-hosted is rarely cheaper — the control-plane fee is trivial next to the SRE time self-managing consumes.
- Managed (EKS/AKS/GKE) is the correct default for the large majority of teams — it is the mature choice, not a compromise.
- Self-hosting is justified by a reason, not a reflex — scale, regulation, bare-metal/edge, or genuine cost-at-huge-scale, never a wish to save $73 a month.
- You always own the worker nodes — the only question is whether you also own the control plane above them.
The TL;DR comparison
What "managed" and "self-hosted" actually mean
Managed Kubernetes means a cloud provider runs the control plane for you. Amazon EKS, Azure AKS, and Google GKE all operate the API server, etcd, scheduler, and controller manager as a service you never log into. You bring workloads and, usually, worker nodes; the provider keeps the brain of the cluster alive and patched, and puts an uptime SLA on it.
Self-hosted Kubernetes means you run the whole thing. You stand up and operate the control plane yourself with a tool like kubeadm, kops, k3s, or Cluster API, on cloud VMs, on-premises servers, or bare metal. There is no per-cluster fee and no provider SLA. The trade is total control in exchange for total ownership of everything that can go wrong beneath your applications.
The control plane is the whole argument
Strip away the marketing and the managed-versus-self-hosted decision comes down to one component: the control plane. The API server, etcd, scheduler, and controller manager are the brain of a cluster and the most operationally unforgiving part of Kubernetes to run well. etcd in particular is a distributed database that demands careful backups, tuned disk I/O, quorum management, and nerve-wracking upgrades.
Managed services make that component someone else's pager. You never back up etcd or rotate control-plane certificates. Self-hosting hands all of it back to you. Every other difference in this comparison — cost, upgrades, security, portability — flows from this single question of who owns the control plane and its blast radius.
The honest cost comparison
Here is where teams talk themselves into the wrong decision. Managed control planes carry a visible fee: roughly $0.10 per cluster per hour on EKS and AKS, about $73 a month, with GKE's standard tier free. Self-hosting has no such line item, so a spreadsheet makes it look free. It is not.
The real cost of self-hosting is engineering time. Someone has to own etcd backups, control-plane availability, certificate rotation, upgrade rehearsals, and the 2 a.m. incident when the API server falls over. Done properly that is a meaningful fraction of one to several SRE salaries — numbers that dwarf a $73 monthly fee at any realistic scale. "Free" self-hosted Kubernetes is rarely cheaper once you price the humans.
The math only flips at genuine scale: a large, steady fleet where per-cluster fees and cloud margins add up faster than the fully-loaded cost of a platform team running owned infrastructure. If you are counting single-digit clusters, you are nowhere near that line. Model the cost honestly — our notes on cloud billing and FinOps cover how to compare the two without fooling yourself.
Upgrades, patching, and day-2 ops
Kubernetes ships a new minor version roughly three times a year and supports each for about a year, so upgrades are not optional. With managed services, control-plane upgrades are a one-click or automated-channel operation the provider has tested across millions of clusters. You still own the worker nodes — OS patches, kubelet versions, and draining and rotating nodes during a bump — but managed node groups, Fargate, and GKE Autopilot shrink or eliminate even that.
Self-hosting means you own both halves, including the risky control-plane and etcd upgrades that managed services turn into routine. You write the runbooks, rehearse the rollback, and carry the pager if a version skew breaks the API server. Day-2 operations — the unglamorous work of keeping a cluster healthy — is where self-hosting quietly consumes teams. See our writeup of the three most common Kubernetes migration mistakes, and what in-place pod resize in 1.33 changes for node churn.
Security and compliance
Managed Kubernetes runs a shared-responsibility model. The provider hardens, patches, and audits the control plane and inherits its compliance certifications — SOC 2, ISO 27001, PCI, FedRAMP, and the rest — so you are not benchmarking etcd against CIS yourself. You remain responsible for what runs on top: RBAC, network policy, image provenance, and secrets.
Self-hosting gives you the whole surface. You can air-gap a cluster, pin exact versions, and enforce policies no managed service exposes — valuable in defense and sovereign-data settings. But you also own control-plane hardening, patch cadence, and the audit evidence. For some regulated or data-residency regimes a managed control plane is simply not permitted, and self-hosting stops being a choice and becomes a requirement. Our cloud and security work covers both paths.
Node management: the layer you always own
One point of confusion worth clearing up: you own the worker nodes in both models. Managed Kubernetes manages the control plane, not necessarily your compute — what differs is how much of the node lifecycle the provider takes off your plate.
On the managed side, the spectrum runs from self-managed node groups (you pick the image and scaling), to managed node groups (the provider handles provisioning and graceful updates), to serverless nodes like AWS Fargate and GKE Autopilot, where you stop thinking about machines at all and pay per pod. On the self-hosted side you assemble the equivalent yourself: kubeadm for bootstrapping, kops for cluster lifecycle on AWS, or Cluster API for declarative, multi-cloud and bare-metal fleet management. More control, and more to build and maintain.
Choose managed if / choose self-hosted if
Our default recommendation, for the large majority of teams, is managed. Choose managed (EKS, AKS, or GKE) if you have a small platform team, want engineers focused on product rather than etcd, need an uptime SLA on the control plane, or want to inherit the provider's compliance posture. That is most companies, and it is the mature choice, not a compromise.
Choose self-hosted only when a concrete reason forces it: regulation or data-residency rules that forbid a managed control plane; bare-metal or edge deployments where no managed offering runs; genuine cost-at-huge-scale, where a large steady fleet makes owned infrastructure cheaper than per-cluster fees; or deep customization, such as a custom scheduler, an unusual CNI, or control-plane flags managed services do not expose. Wanting to save the control-plane fee is never a sufficient reason on its own.
This is the same buy-versus-build calculus we walk through for teams weighing managed DevOps versus an in-house team. The right answer depends on scale, staffing, and risk — not on which option looks cheapest in a spreadsheet.
Managed versus self-hosted comes down to who should own the control plane given your scale, staffing, and constraints. For most teams the honest answer is managed; self-hosting should be a deliberate decision backed by a real reason. Get it wrong either way and you pay — in a fragile hand-rolled control plane, or in cloud fees you never needed. Our DevOps team helps you choose and run either.
Not sure whether managed or self-hosted is right for you? InfraZen runs a free 30-minute architecture review that ends in honest, unbiased advice — including "stay on managed" when that is the truth. Book the review.
Related: Managed DevOps vs in-house · DevOps vs SRE vs Platform Engineering · What is DevOps? · SRE consulting · Kubernetes GPU cost · Blog · Case studies