vault

Managed Kubernetes Services

10 min read

Managed Kubernetes Services

A managed Kubernetes service is a cloud offering in which the provider runs the control plane for you — the API server, etcd, scheduler, and controller-manager all run on the provider’s infrastructure, invisible and inaccessible: you do not SSH into them, you do not patch them, you do not back up etcd (Kubernetes — Components). What you receive is a Kubernetes API endpoint and a kubeconfig; what you manage is everything above that line — worker nodes (or, in serverless modes, not even those), your workloads, your RBAC, your network policy, your add-ons. This is a shared-responsibility split, and it is the single most important thing to understand before choosing a service. The market is dominated by the “big three” — Amazon EKS, Google GKE, Azure AKS — joined by Oracle OKE, IBM Cloud Kubernetes Service, DigitalOcean DOKS, Linode LKE, and many more. The Kubernetes MOC decision framework states the default bluntly: choose managed Kubernetes unless you have a specific reason not to — the operational cost of running your own control plane dwarfs the per-cluster fee the cloud charges.

Mental Model

flowchart TB
    subgraph CLOUD["Cloud provider's responsibility"]
        CP["Control plane<br/>API server · etcd · scheduler · controller-manager"]
        CPHA["Multi-AZ replication · upgrades · etcd backups · SLA"]
    end
    LINE["═══  the managed boundary — your kubeconfig endpoint  ═══"]
    subgraph YOU["Your responsibility"]
        NODES["Worker nodes / node modes<br/>(self-managed · managed groups · serverless)"]
        WL["Workloads · Deployments · StatefulSets"]
        SEC["RBAC · NetworkPolicy · Pod Security · IAM bindings"]
        ADDON["Add-ons · ingress controllers · CNI choices · observability"]
        UPG["Triggering version upgrades · node patching"]
    end
    CP --- CPHA
    CPHA --- LINE
    LINE --- NODES
    NODES --- WL --- SEC --- ADDON --- UPG

What this shows. One horizontal line divides the world. Below the cloud’s control plane and above your workloads sits “the managed boundary” — your API endpoint. The cloud owns control-plane availability, multi-AZ replication, etcd durability, and the control-plane SLA. You own everything from the worker nodes up. The insight to extract: “managed” does not mean “hands-off.” It removes one specific, brutal category of work — control-plane operations — and leaves a large amount of work (node lifecycle, security posture, add-ons, upgrade triggering) firmly with you. Misjudging where the line sits is the leading cause of “I thought the cloud handled that” incidents.

Mechanical Walk-through

What the cloud provider owns. The provider runs the control plane on its own infrastructure (internally, using a hosted-control-planes-style architecture — control-plane components as workloads on the provider’s fleet). The provider guarantees the control plane’s availability (each of EKS/GKE/AKS publishes a control-plane SLA, typically 99.95% for the paid/regional tier), spreads control-plane replicas across multiple availability zones, takes and retains etcd backups, and performs control-plane version upgrades (you pick the target version; the cloud executes the upgrade). Control-plane scaling — adding API server capacity as the cluster grows — is automatic and invisible. You never see a control-plane node, never hold its kubeconfig-to-the-host, never run etcdctl.

What you own. Everything above the API endpoint. Concretely: worker nodes — their OS image, their patching cadence, their instance types, their count (unless you opt into a serverless mode); workloads — every Deployment, StatefulSet, Job; security posture — RBAC, NetworkPolicy, Pod Security Standards, and the cloud-IAM-to-Kubernetes bindings (workload identity); add-ons — ingress controllers, the choice of CNI where the provider allows it, observability stacks, autoscalers; and crucially upgrade triggering — the cloud will upgrade the control plane when you tell it to (or on a channel cadence you opt into), and node upgrades are usually yours to schedule.

Control-plane pricing models. Three patterns exist. (1) Per-cluster-hour fee — EKS charges a flat ~$0.10 per cluster per hour for the control plane regardless of size; AKS charges per-cluster for its SLA-backed tier (and historically offered a free, no-SLA tier). (2) Free control plane — GKE has, at various points, made the control plane management fee free for one zonal cluster per billing account and charged a flat per-cluster fee otherwise; the worker compute is always billed. (3) Bundled into a serverless mode — in fully-serverless modes you pay only for the resources your Pods request and the control plane is folded into that price. In all models you separately pay for worker compute (or, in serverless modes, per-Pod resource requests).

Node management modes. This is where the services differentiate. There is a ladder of how much node operation you delegate:

  1. Self-managed node groups — you create the cloud autoscaling group / instance template yourself, you own the OS image and bootstrap. Most control, most work. (EKS self-managed nodes; GKE has historically de-emphasized this.)
  2. Managed node groups / node pools — the provider creates and lifecycle-manages a group of worker nodes: provisioning, OS image, graceful draining on upgrade. You still pick instance type and count (or attach an autoscaler). This is EKS managed node groups and GKE Standard node pools.
  3. Fully serverless / nodeless — you never see a node at all; you submit Pods and the provider provisions exactly the compute each Pod needs, billing per-Pod resource request. This is AWS Fargate for EKS, EKS Auto Mode, and GKE Autopilot. Maximum delegation, a price premium, and some constraints on what Pods can do (e.g., no privileged Pods, no DaemonSet host access on Fargate).

The general rule: move down the ladder unless a specific need (custom kernels, GPU specifics, DaemonSets, cost-at-scale) pulls you up.

Configuration / API Surface

The three big providers each have a CLI for cluster creation. Side by side:

# Amazon EKS — eksctl (community) generates the CloudFormation under the hood.
eksctl create cluster --name prod --region us-east-1 \
  --version 1.30 \
  --nodegroup-name ng-1 --node-type m6i.large --nodes 3   # a MANAGED node group
 
# Google GKE — Autopilot mode: no node config at all, Google manages compute.
gcloud container clusters create-auto prod \
  --region us-central1 \
  --release-channel regular                               # control-plane version channel
 
# Azure AKS — paid SLA tier, system + user node pools.
az aks create --resource-group rg --name prod \
  --kubernetes-version 1.30 \
  --tier standard \                                        # the SLA-backed tier
  --node-count 3 --node-vm-size Standard_D4s_v5

Line-by-line: every command picks a Kubernetes version (the control plane version — the cloud runs the upgrade when you bump it). The EKS command explicitly defines a managed node group (instance type + count). The GKE create-auto command defines no nodes whatsoever — Autopilot provisions compute per Pod — and instead picks a release channel (the control-plane upgrade cadence). The AKS command picks a --tier — standard is the SLA-backed paid control-plane tier; the cheaper free tier has no control-plane SLA and is development-only. After creation, all three drop a kubeconfig and from then on it is the same Kubernetes — kubectl, Helm, GitOps all work identically.

Failure Modes

Misjudging the responsibility line. “The cloud manages Kubernetes, so it patches my nodes / sets my RBAC / configures network policy.” It does not. Worker-node CVEs, over-broad RBAC, missing default-deny NetworkPolicy — all yours. The single most expensive managed-Kubernetes misconception.

Control-plane SLA only on the paid/regional tier. AKS’s free tier and GKE’s zonal clusters have a single-zone or unreplicated control plane and a lower (or no) SLA. A zonal-cluster control plane dies in an AZ outage. Production clusters belong on the regional / SLA-backed tier; the cost delta is small, the resilience delta is large.

Version end-of-life forcing an upgrade. The cloud supports each Kubernetes minor version only for a window (roughly 14 months on GKE standard support; comparable on EKS/AKS). When a version reaches EOL the cloud will force an upgrade. Clusters left to drift get auto-upgraded on the cloud’s schedule, sometimes surprising teams. Track the version-support calendar.

Serverless-mode constraints. Fully-serverless modes (Fargate, Autopilot) forbid certain Pod shapes — privileged containers, host networking, certain DaemonSets, arbitrary hostPath. Teams that adopt them without auditing their workloads hit “this Pod won’t schedule here” surprises.

CNI / add-on lock-in. Each provider has a default CNI (AWS VPC CNI on EKS, GKE Dataplane V2 on GKE, Azure CNI on AKS) and a curated add-on catalog. Deep dependence on provider-specific add-ons (load-balancer controllers, IAM-integration controllers) is real lock-in even though “it’s just Kubernetes.”

Alternatives and When to Choose Them

Self-Managed Kubernetes (kubeadm, kops, kubespray). You run the control plane yourself. Choose only for: regulatory isolation that forbids a shared/cloud control plane, on-prem or air-gapped deployment, specialized hardware the cloud doesn’t offer, deep control-plane customization (custom admission plugins, custom scheduler builds), or genuine multi-cloud abstraction needs. For everyone else, the operational savings of managed dwarf the per-cluster fee.

Lightweight Kubernetes Distributions (k3s, k0s, microk8s). For edge, IoT, branch-office, or dev — single-binary, low-footprint clusters. Not a managed service; you operate it, but the operational surface is tiny.

Kamaji / hosted control planes on your own management cluster. The self-hostable version of what managed services do internally — useful when you want the hosted-control-plane economics on-prem or across heterogeneous infrastructure.

OpenShift (managed variants: ROSA, ARO, OpenShift Dedicated). Red Hat’s opinionated distribution, available as a managed offering on AWS/Azure. Choose when the OpenShift developer experience and built-in security posture are wanted and the opinionated-ness is acceptable.

Choosing between EKS, GKE, and AKS is usually decided by which cloud you are already on — the deep value is in the IAM, networking, and load-balancer integration with the rest of that cloud. On a greenfield basis, GKE is frequently cited as the most mature; see Google GKE, Amazon EKS, Azure AKS.

Production Notes

  • “Choose managed unless you have a specific reason not to.” The Kubernetes MOC decision framework’s blunt default. The number of teams that should run their own control plane is small; the number that do and regret it is large.
  • The control-plane fee is a rounding error. EKS’s ~73/month. Against an SRE’s time spent on etcd backups, control-plane upgrades, and leader-election debugging, it is not a real cost. The real cost is worker compute, and that exists in every model.
  • Cluster count is the hidden cost driver. A flat per-cluster control-plane fee multiplied across a fleet of dozens of clusters adds up — this is one motivation for vCluster (many virtual clusters, one real one) and Kamaji (many hosted control planes, one management cluster).
  • Regional/HA tier is non-negotiable for production. Every provider’s cheap tier trades the control-plane SLA away. Use it for dev; never for production.
  • Provider parity has converged. EKS, GKE, and AKS have all converged on the same feature set — managed node groups, a serverless mode, workload identity, release channels, autoscaling. The differences are now at the margin (GKE’s Autopilot maturity, EKS’s deep AWS integration, AKS’s Azure AD integration) and in how well each integrates with the rest of its cloud.

See Also

Graph View

Backlinks