Azure Kubernetes Service (AKS) has one advantage over its AWS and GCP equivalents that's easy to undersell: the Free tier control plane costs nothing at all, not even a token hourly fee. 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 makes the managed option's economics hard to beat even with the added flat fee.

Cost shape to expect

Even on Standard tier, the control-plane fee is a flat, modest hourly charge — nowhere near what running your own control-plane infrastructure costs in engineering time. That means 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.