Azure Kubernetes Service (AKS) has one advantage over its AWS and GCP equivalents that's easy to undersell: the control plane is free on the standard tier, not billed hourly. That changes the cost conversation slightly, but the operational decision — managed vs. self-managed — still comes down to the same fundamentals as any cloud.

The tiers that actually matter

Tier Control plane SLA Cost Best for
Free No SLA (best-effort) No control plane charge Dev/test, internal tooling
Standard Financially-backed 99.95% SLA Flat hourly control plane fee Production workloads
Premium Standard SLA + extended Kubernetes version support Higher flat fee Regulated environments needing longer version support windows

For a genuinely production-facing service, Standard tier is the right default — the SLA is worth the modest flat fee the moment the cluster carries real traffic.

Provisioning a cluster

az aks create \
  --resource-group prod-rg \
  --name prod-aks \
  --tier standard \
  --node-count 3 \
  --node-vm-size Standard_D4s_v5 \
  --enable-managed-identity \
  --network-plugin azure \
  --generate-ssh-keys \
  --enable-addons monitoring

--enable-addons monitoring wires Container Insights into every node automatically — worth enabling on the first cluster rather than retrofitting once something's already on fire. --enable-managed-identity means the cluster itself authenticates to other Azure services (ACR, Key Vault) without a stored credential.

Where AKS differs from EKS/GKE in practice

Most Kubernetes-native tooling — Helm, kubectl, ArgoCD, Prometheus — behaves identically once you're inside the cluster. The differences that actually change day-to-day operations:

  • The CNI choice matters more than on other clouds. azure (Azure CNI) assigns a real VNet IP to every pod, which simplifies network policy and peering with other Azure resources, but consumes VNet address space fast at scale. kubenet conserves IPs but adds a routing hop. Pick azure CNI unless you have a specific IP-exhaustion constraint — the peering simplicity is worth it for most teams.
  • Load Balancer annotations use the service.beta.kubernetes.io/azure-load-balancer-* prefix, not AWS's aws-load-balancer-* or Alibaba's alibaba-cloud-loadbalancer-*. Easy to carry the wrong prefix over mid-migration and have it silently ignored.
  • The CSI driver for persistent volumes backs onto Azure Disk or Azure Files, with StorageClasses named managed-csi and azurefile-csi by default — not the AWS EBS or Alibaba Cloud Disk tier names a migrating team might expect.
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: managed-premium-retain
provisioner: disk.csi.azure.com
parameters:
  skuName: Premium_LRS
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer

Autoscaling: cluster autoscaler and node pools

AKS separates node pools cleanly, which makes mixed-workload clusters easier to reason about than a single undifferentiated node group:

az aks nodepool add \
  --resource-group prod-rg \
  --cluster-name prod-aks \
  --name spotpool \
  --priority Spot \
  --eviction-policy Delete \
  --spot-max-price -1 \
  --enable-cluster-autoscaler \
  --min-count 0 \
  --max-count 10

Spot node pools (--priority Spot) are Azure's answer to AWS spot instances and Alibaba's preemptible instances — same trade-off, meaningfully cheaper compute for anything that tolerates interruption. Batch jobs and stateless workers belong here; anything stateful doesn't.

When self-managed still wins

I've reached for self-managed Kubernetes on Azure VMs exactly once, and the reason was identical to the Alibaba Cloud case I've hit before: a compliance requirement mandating full control-plane audit access with no managed-service data path at all. Outside that specific constraint, the operational cost of running your own etcd, API server certificate rotation, and version upgrades isn't worth what you get back — AKS Standard tier's SLA and free control plane make the managed option's economics hard to beat.

Cost shape to expect

Because the control plane itself is free (Standard tier's fee is flat and modest), AKS's total cost is dominated almost entirely by node VM size and count — closer to a pure compute bill than EKS's combined control-plane-plus-compute model. That makes AKS cost modeling simpler in practice: right-size the node pools and the autoscaler, and the bill follows fairly predictably.