AKS

How it works

In AKS, Azure operates the Kubernetes control plane (the API server, etcd, scheduler and controller manager) and you manage the worker nodes through node pools. Each node pool is backed by a virtual machine scale set, so you can run different VM sizes, Linux and Windows nodes, or spot capacity side by side in one cluster.

Cluster management has three pricing tiers: Free, Standard and Premium. Microsoft’s documentation describes Free as intended for development, test and small clusters, with no financially backed uptime SLA. Standard adds an uptime SLA and is intended for production. Premium adds Long Term Support for Kubernetes versions on top of the SLA. In every tier you also pay for the resources the cluster consumes, such as node VMs, managed disks, load balancers and network egress. Check the current Azure pricing page for amounts.

Identity uses Microsoft Entra ID (formerly Azure AD) for authentication, combined with Kubernetes RBAC or Azure RBAC for authorisation. Networking options include kubenet and Azure CNI, where pods receive addresses from a virtual network. Images usually come from Azure Container Registry, and metrics and logs flow to Azure Monitor.

A practical example

Creating a small cluster in the Free tier for testing with the Azure CLI:

az aks create \
  --resource-group my-rg \
  --name my-aks \
  --tier free \
  --node-count 2 \
  --generate-ssh-keys

Moving the same cluster to production later is a tier change (az aks update --tier standard), not a rebuild.

Common mistakes

• Treating the Free tier as production ready. It has no financially backed uptime SLA.
• Choosing a pod network plugin without planning address space. Azure CNI consumes virtual network addresses for pods, so undersized subnets limit scaling.
• Leaving node pools on unsupported Kubernetes versions. Plan regular upgrades rather than waiting for forced ones.
• Running everything in a single system and user node pool, which makes upgrades and sizing harder to manage.
• Granting broad cluster admin rights instead of scoped RBAC roles.

When to use it and when not to

AKS is a good fit when your organisation already uses Azure, Microsoft Entra ID or Windows workloads, and you want Azure to run the control plane. It is less suitable if you need to customise control plane components or must run identical tooling across several clouds without any provider specific integration. Compare it with EKS and GKE before deciding.

For design and delivery help, see our AKS consulting service and the wider Kubernetes consulting practice.

See also

• Kubernetes
• EKS
• GKE