Once the decision to migrate to Kubernetes is made (covered in the PME-ETI decision framework, in French), a second question precedes every other one: who operates the cluster. A managed service (EKS, GKE, AKS) and a self-managed cluster (kubeadm, k3s, or the equivalent on your own infrastructure) don’t shift the same workload to the same place.
What the managed provider actually handles
The three major providers manage the control plane (API server, etcd, scheduler, controller-manager): its high availability, version upgrades, security patches. That’s a real transfer of responsibility, not a cosmetic one: a poorly operated etcd is one of the most common causes of a major cluster incident, and it’s exactly the part that disappears from your list of concerns.
# What stays identical regardless of provider:
# kubectl talks to the same control plane, with the same verbs
kubectl get nodes
kubectl apply -f deployment.yamlWhat the managed control plane doesn’t cover, in all three cases: worker nodes remain your responsibility for sizing, OS upgrades, and often a non-trivial share of security (kernel patches, CIS Benchmark configuration). EKS Fargate, GKE Autopilot, and AKS Automatic push the abstraction further by managing nodes too, at the cost of reduced flexibility over what can run on them (DaemonSets and elevated privileges are often restricted or forbidden).
The hidden cost of self-managed: time, not just servers
A self-managed cluster eliminates the control-plane management fee providers charge (roughly a few tens to a hundred euros per month per cluster depending on the provider), but shifts that cost to engineering time: someone has to master zero-downtime etcd upgrades, internal control-plane certificate rotation, and incident response on that same critical infrastructure, often on a weekend. For a single, modest-sized cluster, that time far exceeds the savings on the bill; the equation flips as the number of clusters grows, because the acquired skill spreads across more infrastructure.
The real criterion: existing in-house skill, not the sticker price
A team already operating its own Linux servers, with an established on-call culture and operational practice, absorbs self-managed at a reasonable marginal cost: the baseline skill exists, Kubernetes gets added on top. A team that has never operated low-level infrastructure pays, with self-managed, a double learning curve (Kubernetes and the systems operations that go with it) that managed largely absorbs on its behalf. The choice also plays out differently under data sovereignty or location constraints: some regulated contexts require full control over the underlying infrastructure that even a managed service on a public cloud doesn’t satisfy.
What stays the same either way
GitOps at scale, progressive rollout strategies, secrets management: none of that depends on who operates the control plane. A well-run managed cluster and a well-run self-managed cluster converge on the same team practices once the control plane is out of the equation; that’s the part of the decision that matters most once you’ve chosen, and it’s identical on both sides.
Takeaway
The choice between managed and self-managed Kubernetes isn’t decided by the control plane’s sticker price, but by the systems-operations skill already present in-house and any sovereignty constraints. A managed provider transfers the most critical load (etcd, API server) for a recurring bill; self-managed transfers that same load to engineering time, only worthwhile if the baseline skill already exists. This choice gets made at the very start of a Kubernetes migration, before the first service is even migrated.