Managed Kubernetes vs Self-Managed Kubernetes in Azure
AKS is a managed Kubernetes service where Microsoft operates the control plane and handles many cluster lifecycle tasks. Self-managed Kubernetes on Azure VMs means you own everything. For almost all teams, AKS is the correct choice — but understanding exactly why helps you identify the narrow set of scenarios where self-managed might still make sense.
What each approach requires
AKS (managed): You create an AKS cluster, define node pools, and start deploying workloads. Microsoft manages the Kubernetes control plane (API server, etcd cluster, scheduler, controller manager) — including its high availability, backups, certificate rotation, and version compatibility. You manage node pools (the worker VMs), cluster networking, and all workloads deployed to the cluster. You initiate upgrades; AKS handles the control plane upgrade mechanics.
Self-managed Kubernetes: You provision VMs for control plane nodes (typically 3 for HA), bootstrap the cluster with kubeadm or a comparable tool, configure etcd with regular backups to a storage account, generate and rotate TLS certificates, install and manage CNI plugins, install and maintain an Ingress controller, and handle every Kubernetes upgrade by running the upgrade process on each node yourself. If etcd becomes corrupted or a control plane node fails, you are responsible for recovery.
Head-to-head comparison
| Dimension | AKS (managed) | Self-managed on Azure VMs |
|---|---|---|
| Control plane cost | Free | 3× Standard_D2s_v5 (~$210/month) for HA control plane |
| Control plane management | Managed by Microsoft | Fully your responsibility |
| etcd backup and restore | Handled by Microsoft | You must configure and test backup/restore |
| Certificate rotation | Automatic | Manual or scripted — failure causes cluster outage |
| Kubernetes version upgrades | Managed upgrade paths, auto-upgrade options | Fully manual, your risk |
| SLA | 99.95% uptime SLA for Standard tier (with Availability Zones) | No SLA — depends entirely on your implementation |
| Microsoft support | Full support for cluster and control plane issues | Only Azure infrastructure support — no Kubernetes support |
| Kubernetes version choice | Three most recent minor versions | Any version (including EOL versions) |
| Feature availability | Azure CNI, OIDC, Workload Identity, Managed Identity, AGIC, ACR integration | Manual integration for everything |
Cost comparison
The AKS control plane being free is not a small detail — it is a material cost difference. A self-managed HA Kubernetes cluster requires at minimum three control plane VMs to survive a node failure (the etcd quorum requires an odd number of nodes with at least 3 for HA).
Three Standard_D2s_v5 VMs in East US on pay-as-you-go: approximately $70/month each = $210/month just for control plane nodes. With 1-year reserved instances this drops to approximately $135/month, but it is still $135/month for infrastructure that does zero application work.
AKS control plane cost: $0/month. The saving is immediate and permanent. For a cluster running for 3 years, that is $6,000–7,500 in control plane VM cost avoided — before accounting for the engineering time saved by not managing those nodes.
AKS has a Standard tier (paid) and a Free tier. The Free tier has no SLA and is appropriate for development clusters only. Production clusters should use Standard tier, which currently adds no cost for the control plane itself — the SLA upgrade is included in the existing pay-for-node-VMs model.
The upgrade reality
Kubernetes releases a new minor version approximately every 4 months. Each version receives approximately 14 months of upstream support. That means you need to upgrade your cluster at least once per year to stay on a supported version.
An AKS upgrade is initiated with a single CLI command. AKS cordons and drains nodes, upgrades the control plane, upgrades node pools rolling one node at a time, and returns the cluster to a running state. The process is transparent and well-documented.
# Upgrade an AKS cluster to a new Kubernetes version
az aks upgrade \
--resource-group myResourceGroup \
--name myAKSCluster \
--kubernetes-version 1.30.5 \
--yesA self-managed upgrade requires running kubeadm upgrade plan, then kubeadm upgrade apply on each control plane node in sequence, then upgrading kubelets on each worker node individually. A misconfigured upgrade can leave etcd in a split-brain state, requiring manual recovery from backup. The operational risk of self-managed upgrades is significant.
When self-managed Kubernetes might make sense
There are narrow scenarios where self-managed Kubernetes on Azure VMs is legitimately chosen:
- Specific Kubernetes version requirements: If a compliance framework, vendor software, or integration requires an older Kubernetes version that AKS no longer supports, self-managed on VMs allows running EOL versions (at your own security risk).
- Custom Kubernetes distributions: Some organisations standardise on a specific Kubernetes distribution (e.g., RKE2, k3s, OpenShift) that has its own commercial support model. Running these on Azure VMs is the only option.
- Multi-cloud consistency: If an organisation runs the same Kubernetes tooling across AWS, GCP, and Azure using a consistent self-managed setup for operational consistency, this may justify the overhead even in Azure.
- Control plane customisation: Extremely unusual admission webhooks, custom schedulers, or API server flags that AKS does not expose may require a self-managed control plane.
Running self-managed Kubernetes in production without a dedicated Kubernetes engineer who understands etcd, kubeadm, certificate management, and network troubleshooting is a significant operational risk. An etcd corruption event on a self-managed cluster with no tested backup process is a data-loss scenario.
AKS features unavailable in self-managed
AKS includes native Azure integrations that would require significant manual effort to replicate on self-managed clusters:
- Workload Identity — pods authenticate to Azure services using managed identities without credentials
- Azure Container Registry pull integration — node pool VMs automatically have pull access to ACR
- Azure Monitor Container Insights — managed monitoring with no Prometheus/Grafana setup
- Application Gateway Ingress Controller (AGIC) — managed Layer 7 Ingress backed by Azure Application Gateway
- Azure CNI Overlay — efficient networking with no IP exhaustion risk from the older Azure CNI model
- Node auto-provisioning (preview) — automatic node SKU selection based on pending pod requirements
Common mistakes
- Choosing self-managed for “more control” without a plan to exercise that control. Most teams that choose self-managed Kubernetes for control never use the additional control surface. They just end up doing more operational work for no benefit.
- Not having a tested etcd backup and restore procedure. If you run self-managed Kubernetes and your etcd backup has never been tested for restore, you do not actually have a backup — you have files whose correctness is unknown.
- Running self-managed control plane on the same nodes as worker workloads. Control plane and worker nodes should be separate. Running etcd alongside application pods introduces resource contention and increases the blast radius of a noisy neighbour pod.
- Skipping AKS because of perceived cost without checking that the control plane is free. A common misconception is that AKS costs more than self-managed because “managed services always cost more.” AKS control plane is free; self-managed control plane VMs are not.
Summary
- AKS provides a free managed Kubernetes control plane with an SLA, managed upgrades, certificate rotation, and native Azure integrations — self-managed provides none of these.
- Self-managed HA Kubernetes requires approximately $135–210/month in control plane VMs plus significant ongoing engineering time — AKS eliminates both costs.
- The cases for self-managed Kubernetes are narrow: EOL version requirements, specific distributions, or multi-cloud tooling standardisation. For standard workloads, AKS is the correct choice.
- AKS upgrades are a single CLI command. Self-managed upgrades are multi-step, error-prone, and carry real risk of etcd corruption without a tested backup procedure.
Frequently asked questions
Is the AKS control plane really free?
Yes. The AKS control plane (API server, etcd, scheduler, controller manager) is free. You pay only for the node VMs, managed disks, load balancers, and other Azure resources in the cluster. The free control plane is one of the primary reasons AKS costs less than self-managed Kubernetes where you must pay for control plane VM infrastructure.
Can I use any Kubernetes version on AKS?
AKS supports the three most recent minor Kubernetes versions (e.g., 1.30, 1.29, 1.28). Older versions reach end-of-support and Microsoft eventually stops supporting clusters on those versions. You cannot run arbitrary old Kubernetes versions on AKS. Self-managed clusters have no such constraint but also have no Microsoft SLA.
What does "self-managed Kubernetes" mean on Azure?
Self-managed Kubernetes on Azure means provisioning Azure VMs and installing Kubernetes yourself using tools like kubeadm, RKE2, or k3s. You are responsible for the control plane VMs, etcd backup and restore, certificate rotation, version upgrades, and all operational tasks. There is no Microsoft support for the Kubernetes layer.