Managed Kubernetes (EKS, GKE, AKS)

Running Kubernetes yourself means running its “brain” — the control plane — and keeping it patched, secure, and highly available. That is hard, thankless work, and getting it wrong can take your whole cluster offline. A managed Kubernetes service is a cloud provider running that control plane for you, so you only worry about your apps. In 2026 this is how almost every production cluster runs, and for good reason — it removes the riskiest, most tedious part of Kubernetes while keeping everything else exactly the same.

What “managed” actually means

A Kubernetes cluster has two halves. The control plane is the brain — the components that schedule containers, watch for failures, and store the cluster’s state in a database called etcd. The worker nodes are the machines that actually run your containers. The control plane is the part that is fiddly to run: it must be highly available (running on several machines so one failure does not kill it), regularly upgraded, and carefully secured.

With a managed service, the cloud provider runs the entire control plane on infrastructure you never see or touch. You do not SSH into it, you do not patch it, and you do not pay for its servers directly. You get a single API endpoint to talk to with kubectl (the Kubernetes command-line tool, pronounced “cube-control”). You still own and pay for the worker nodes, but even those are easy to create and replace.

The key idea: managed Kubernetes is still real Kubernetes. Your YAML files, kubectl commands, and Helm charts work identically. You are outsourcing the operations, not changing the platform.

The cost and effort savings

Self-hosting a production-grade control plane realistically takes a dedicated engineer and weeks of setup, plus ongoing upgrade work every few months. A managed cluster is ready in minutes. Here is what you stop having to do.

Task	Self-hosted	Managed
Install and configure control plane	You, manually	Done for you
Make control plane highly available	You run 3+ master nodes	Built in
Patch and upgrade the control plane	You, on a schedule	One click / one command
Back up etcd	You set it up	Done for you
Worker node OS patching	You	Optional auto-upgrade
3 a.m. control plane outage	Your pager	Provider’s pager

On most clouds the control plane is either free or a flat fee (around 7-10 cents per cluster per hour, roughly 70 USD a month), and you pay normally for the worker nodes. That fee is far cheaper than the engineer-hours self-hosting would burn.

Comparing the main options

The three big clouds each have their own offering, plus simpler choices from smaller providers.

Service	Provider	Control plane cost	Best when
EKS (Elastic Kubernetes Service)	AWS	~$0.10/hr per cluster	You already use AWS (IAM, VPC, RDS).
GKE (Google Kubernetes Engine)	Google Cloud	First cluster free, then ~$0.10/hr	You want the smoothest, most “auto” experience.
AKS (Azure Kubernetes Service)	Microsoft Azure	Free control plane (pay nodes only)	You are in the Microsoft / enterprise world.
DOKS	DigitalOcean	Free control plane	You want simple, cheap, and predictable pricing.
LKE	Akamai (Linode)	Free control plane	Same as DOKS — small teams, low cost.

GKE is widely regarded as the most polished, partly because Google created Kubernetes. EKS wins when the rest of your stack already lives on AWS, because it plugs into AWS identity and networking. AKS is the natural pick inside Microsoft shops. DigitalOcean (DOKS) and Linode (LKE) are the friendliest for individuals and small teams — flat, predictable pricing, a free control plane, and far less surface area to learn than the big three.

Connecting to a managed cluster from Ubuntu

The workflow is almost identical everywhere: install the provider’s CLI, run one command to create the cluster, and it writes the connection details into your kubeconfig (the file at ~/.kube/config that tells kubectl which cluster to talk to). Here is the DigitalOcean path on Ubuntu 22.04/24.04, because it is the simplest to follow.

sudo snap install kubectl --classic
sudo snap install doctl
doctl auth init
doctl kubernetes cluster create demo --region nyc1 \
  --node-pool "name=pool-1;size=s-2vcpu-2gb;count=2"

Output:

Notice: Cluster is provisioning, waiting for cluster to be running
....................................
Notice: Cluster created, fetching credentials
Notice: Adding cluster credentials to kubeconfig file found in "/home/you/.kube/config"
Notice: Setting current-context to do-nyc1-demo
ID                                      Name    Region    Status
b3...e1                                 demo     nyc1     running

The create command automatically updated your kubeconfig, so kubectl is already pointed at the new cluster. Confirm the worker nodes are healthy.

kubectl get nodes

Output:

NAME            STATUS   ROLES    AGE   VERSION
pool-1-abc12    Ready    <none>   1m    v1.33.1
pool-1-abc34    Ready    <none>   1m    v1.33.1

The pattern is the same on AWS (eksctl create cluster ...), Google Cloud (gcloud container clusters create ...), and Azure (az aks create ...) — each tool finishes by writing your kubeconfig so kubectl just works.

When managed is the right call

For production, the answer is almost always yes, use managed. The only common reasons to self-host are strict rules that forbid using a public cloud (some government or regulated workloads), running entirely on your own hardware, or building a cluster purely to learn how the control plane works.

Situation	Recommendation
Production app on a public cloud	Managed — always start here.
Small team without a dedicated ops engineer	Managed — you cannot afford the upkeep.
Learning Kubernetes locally	Use Minikube or kind, not managed.
Air-gapped / on-premises only	Self-host (kubeadm, k3s, RKE2).
You enjoy operating control planes for fun	Self-host — but know what you signed up for.

Gotcha: “managed control plane” does not mean “managed everything.” You still right-size and pay for worker nodes, set resource limits, configure autoscaling, and watch your bill. A forgotten node pool or an over-provisioned load balancer can quietly cost hundreds of dollars a month.

Best Practices

Default to a managed service (EKS, GKE, AKS, DOKS) for anything production — only self-host when a hard requirement forces it.
Pick the provider where the rest of your infrastructure already lives, so identity and networking integrate cleanly.
Enable node auto-upgrade and cluster autoscaling so the provider keeps nodes patched and right-sized for you.
Never run a single node pool with one node in production — use at least two nodes across availability zones for resilience.
Keep your kubectl client version within one minor release of the cluster to avoid compatibility surprises.
Set a billing alert from day one; managed control planes are cheap, but idle nodes and load balancers are not.
Store cluster creation steps as code (Terraform or the provider CLI in a script) so you can recreate the cluster reliably.