← Back to blog

Self-managed Kubernetes vs managed control plane: when it's worth it

kubernetesinfrastructureclouddevopscost
Self-managed Kubernetes vs managed control plane: when it's worth it

If you have to ask whether to run your own Kubernetes control plane, the answer is almost certainly no — pay for the managed one. I run a self-managed cluster on my own hardware, and I still tell most teams to use EKS, GKE or AKS. The control-plane fee is the cheapest line item on the bill and the most expensive thing to get wrong yourself.

This is a narrower question than “should I leave the cloud.” That broader argument — bare metal versus AWS on price-per-spec, egress, the whole owned-hardware economics — I wrote about separately in When bare metal beats the cloud. This post is one decision inside that: given you’re running Kubernetes, should the control plane — the API server, etcd, the scheduler, the controllers — be something a cloud provider operates for you, or something you operate yourself? The two questions have different answers, and conflating them is how people end up running etcd at 2am for no good reason.

What the managed control plane actually is

A Kubernetes cluster is two halves. The data plane is your worker nodes — the machines that run your pods. The control plane is the brain: the API server everything talks to, etcd holding the entire cluster state, the scheduler deciding where pods land, the controller-manager reconciling reality against your manifests. When you run Kubernetes yourself, you own both halves. When you use a managed service, the provider runs the control plane and you bring the workers (or, increasingly, let them run those too).

The provider provisions, operates, patches and scales the control-plane components — kube-apiserver, etcd, controller-manager — so you don’t run them yourself (Plural, AWS Managed Kubernetes guide, Jun 2026). That is the entire product. You’re not paying for compute on the control plane — that’s bundled. You’re paying someone to be on the hook for the one part of the cluster that, if it breaks, takes everything down with it.

What it costs — the actual numbers

The three big managed offerings price the control plane almost identically, which tells you something about how settled this market is.

EKS (AWS): $0.10/hour per cluster — about $73/month — for the managed control plane, before a single worker node (AWS EKS pricing, Jun 2026). The catch is version support. A Kubernetes version gets 14 months of standard support; after that, the cluster drops into extended support and the fee jumps 6x to $0.60/hour — roughly $438/month per cluster (Cloud Burn, EKS pricing 2026, Jun 2026). That increase is not a penalty AWS invented to be cruel. It’s the price of them patching a Kubernetes version the upstream project has stopped supporting — which is exactly the work you’d otherwise be doing yourself.

GKE (Google): A flat $0.10/hour per cluster management fee, billed per second, applied to every cluster regardless of Autopilot or Standard mode, size, or topology (Google Cloud, GKE pricing, Jun 2026). GKE is the one that gives you a genuine free tier: $74.40/month in credits per billing account, enough to cover one zonal Standard or Autopilot cluster’s management fee (CloudZero, GKE pricing 2026, Jun 2026). So your first small cluster’s control plane is effectively free; the second one isn’t.

AKS (Azure): Three tiers. Free — no control-plane fee, no financially-backed SLA, not meant to run past 10 nodes. Standard — $0.10/hour ($73/month) for a financially-backed uptime SLA. Premium — $0.60/hour (~$438/month), which adds long-term support for older Kubernetes versions (Microsoft Learn, AKS pricing tiers, Jun 2026). The shape mirrors EKS exactly: base rate for current versions, 6x for the privilege of staying on an old one.

So the number to hold in your head is ~$73/month per cluster for a supported control plane, climbing to ~$438/month if you fall behind on upgrades. That is the whole financial case for self-managing the control plane: on my own hardware, that fee is zero. A cluster costs me the nodes and my own time, nothing per-cluster.

And here is the honest part — for almost everyone, $73/month is not the number that should drive this decision.

What the SLA buys, and what it doesn’t

The fee mostly buys a financially-backed SLA on the API server. EKS, GKE Autopilot, and GKE regional Standard clusters all guarantee 99.95% control-plane uptime; GKE zonal Standard drops to 99.5%; AKS Standard and Premium hit 99.95% with availability zones (Google Cloud, GKE pricing, Jun 2026; Microsoft Learn, AKS pricing tiers, Jun 2026). Read what that covers carefully: it’s the control plane’s availability. Your workloads going down is your problem. The SLA means the API server answers and etcd is intact — it is insurance on the brain, not on the body.

What it does not buy is freedom from responsibility for everything else. Managed Kubernetes creates a grey zone — the provider runs the control plane, but you still own your workloads, networking, IAM, and runtime security (Wiz, Managed Kubernetes, Jun 2026). The managed control plane removes one category of pager load. It removes none of the others. Anyone selling EKS as “Kubernetes without operations” is selling you the easy 20%.

The real cost is upgrades and CVEs, not dollars

Here is the part that decides it. Kubernetes ships a new minor version roughly every four months — about three releases a year — and each version gets 14 months of upstream support: 12 months of fixes plus a 2-month upgrade window (Kubernetes release docs, Jun 2026). You cannot skip versions. kubeadm upgrades go one minor version at a time (Kubernetes EOL, endoflife.date, Jun 2026). So staying supported means an upgrade cadence you do not control, on a clock you did not set.

On a managed control plane, that upgrade is a click or a terraform apply. The provider handles the control-plane half — new minor versions, CVE patches, control-plane scaling (Plural, AWS Managed Kubernetes guide, Jun 2026). On a self-managed cluster, you do it: back up etcd, check for deprecated APIs, verify addon compatibility, upgrade the control-plane nodes one at a time, then the workers one at a time, then validate the whole thing — three times a year, forever (Kubenatives, kubeadm upgrade playbook, Jun 2026).

Then there’s etcd. etcd is the single source of truth for the entire cluster — corrupt or lose it and the cluster is unmanageable. Managed services back it up automatically; self-hosted etcd needs your own backup strategy, restore procedure, and regular restore testing, with snapshots as often as every 15 minutes for critical clusters (OneUptime, etcd backup and recovery, Jun 2026). A backup you have never restored is not a backup; it’s a hope. The teams that learn this learn it the hard way.

The blunt framing I keep coming back to: when something breaks at 2am, self-managed means you’re reading etcd logs, containerd logs, and kernel dmesg; managed means you file a ticket. If your team can’t do the former comfortably, pay for the latter (Plural, AWS Managed Kubernetes guide, Jun 2026). A reasonable budget for self-managing the control plane is on the order of a week of senior engineering time per year just for upgrades and patching — and that’s the happy path, before anything goes wrong. The disaster-recovery tail is far heavier: one vendor’s estimate (vendor: Pelotech) for building Kubernetes DR capability in-house runs $450K–$900K over 18 months once you count personnel, the learning curve, and failed iterations (Pelotech, Kubernetes DR build vs partner, Jun 2026). That number is the answer to “why does AWS charge $0.60/hour to keep you on an old version” — because the alternative is you, spending that.

The decision

Strip it to the load-bearing questions.

Pay for the managed control plane (EKS / GKE / AKS) if:

  • You run a handful of clusters and $73/month each is noise against your total bill. It is. Don’t self-manage to save it.
  • Nobody on the team can comfortably debug etcd, containerd, and the kernel at 2am — and you don’t want to pay to build that muscle.
  • You’d rather your senior engineers ship product than run a three-times-a-year upgrade ritual and quarterly etcd restore drills.
  • You have a compliance or RTO/RPO requirement and want the provider’s financially-backed SLA on the API server as part of your story.

This is most teams. If you’re reading this to decide, you’re probably in this list.

Self-manage the control plane only if:

  • You already run your own hardware for the price-per-spec reasons in the bare-metal post, and the control plane is a small marginal addition to ops you already do.
  • You genuinely have the operational depth — people who have restored etcd from a snapshot, not just read about it.
  • The per-cluster fee actually adds up for you: many clusters, or a per-cluster tax steering you toward fewer, bigger, multi-tenant clusters than your architecture wants. On self-managed, a cluster costs nodes and time, so that architectural choice is made on its merits, not on a meter.
  • Data residency, air-gap, or sovereignty constraints rule the big three out anyway.

I’m in the second list — but I want to be honest about why, because it’s not the reason most people reach for. I don’t self-manage to save $73/month. I self-manage because I already run six dedicated nodes for the hardware economics, I run etcd backups, and the control plane is a small addition to ops I’m doing regardless. The control-plane fee was never my reason to leave, and it shouldn’t be yours. Pay it. It’s the best-value line on the bill — until the day it isn’t, and you’ll know that day when it arrives, not before.