Azure Kubernetes Service

Azure Kubernetes Service is managed Kubernetes: Azure runs the control plane — the API server, scheduler, and etcd — and you run the worker nodes and the workloads on them. You get the full Kubernetes API and its ecosystem of operators, Helm charts, and tooling, without operating the control plane yourself.

AKS is the right choice when you genuinely need Kubernetes — its API for portability, its operator ecosystem, fine-grained control over scheduling and networking. It is the wrong choice when you reached for it out of habit: the operational weight of running clusters, upgrades, and add-ons is real, and Container Apps delivers most of the value for containerized services without it.

Control Plane and Tiers

Azure manages the control plane, and the pricing tier sets the guarantee on it. The Free tier has no uptime SLA and suits dev and test. The Standard tier adds a financially backed control-plane SLA — 99.95% with availability zones, 99.9% without — for a per-cluster hourly fee, and is the production baseline. The Premium tier builds on Standard to add long-term support (two years) for older Kubernetes versions, for teams that cannot upgrade on the roughly-annual community cadence.

Control planeAzure-managed

API server · scheduler · etcd

Azure runs and scales the API server, scheduler, and etcd, and backs the SLA on Standard and Premium. You do not see or patch it.

Node poolsyours

system pooluser pool

You own the worker VMs — a system pool for cluster services and user pools for workloads — and their sizing, patching, and the cluster autoscaler.

Node Pools

Worker nodes are grouped into node pools, each a scale set of a chosen VM size. A system node pool runs cluster services like CoreDNS; user node pools run your workloads. Separating pools by workload — a memory-optimized pool for caches, a GPU pool for inference, a Spot pool for fault-tolerant batch — lets you size and scale each independently.

The cluster autoscaler adds and removes nodes in a pool as pending pods require, so you are not paying for idle nodes or starving pods of capacity. It works alongside the Horizontal Pod Autoscaler, which scales pod replicas; the two operate at different layers.

Networking

The network plugin shapes IP usage and is best decided early. Azure CNI Overlay — the recommended default for most clusters — gives pods IPs from a private overlay CIDR while only the nodes take VNet addresses, so a cluster scales to large pod counts without exhausting the subnet. Traditional Azure CNI assigns every pod a routable VNet IP, which integrates cleanly with Azure networking but consumes address space fast; the older kubenet model conserves IPs at the cost of routing complexity. Azure CNI Powered by Cilium is the recommended data plane for new clusters. Plan pod and node address space up front — you can update the CNI IPAM mode and data plane, but a badly sized traditional-CNI subnet is painful to undo.

Identity and Security

Workload Identity federates a Kubernetes service account with an Entra ID identity, so pods call Azure services with a token and no stored secret. This replaces the old pattern of mounting service-principal credential files, which are long-lived and leak. Azure RBAC for Kubernetes maps Entra identities to cluster permissions, unifying access control with the rest of Azure.

Scaling

AKS scales at three layers: the Horizontal Pod Autoscaler scales pod replicas on metrics, the cluster autoscaler scales nodes to fit the pods, and KEDA scales workloads on external event sources like queue depth. Node autoprovisioning can even pick node sizes automatically. Matching the scaling mechanism to the signal is the difference between a responsive cluster and an over-provisioned one.