Azure AKS
Azure AKS is Microsoft's managed Kubernetes, integrated with the Azure ecosystem — Entra ID for identity, Azure CNI for networking, Azure Disks and Files for storage. It is known for a free control-plane tier and deep Entra integration. As with the other clouds, verify version-sensitive details against current Azure documentation.
AKS is a solid managed offering whose distinctive points are its control-plane pricing model and its identity integration with Microsoft Entra ID.
The Control-Plane Tiers
AKS historically offers a free control-plane tier (you pay only for nodes) alongside a paid Standard tier that adds a financially-backed uptime SLA and higher scale limits. The nuance that catches teams: the free tier gives the control plane on a best-effort basis without the SLA — fine for many workloads, but production systems that need a guaranteed control-plane SLA should choose the paid tier. Confirm the current tier names and terms in Azure docs.
Node Pools
AKS organizes compute into node pools, with a distinction worth knowing: a system node pool runs critical add-on Pods (CoreDNS, etc.) and a user node pool runs your workloads — keeping them separate protects cluster services from application load. Pools can use spot VMs for cheap, interruptible capacity. Node provisioning and upgrades are managed by AKS, with the same drain-and-replace mechanics covered earlier.
Networking
AKS networking centers on Azure CNI, increasingly in Overlay mode, where Pods get IPs from an overlay rather than consuming VNet addresses directly — which sidesteps the IP-exhaustion problem that the AWS VPC CNI can hit. (Legacy kubenet exists but is being phased out.) The result is VNet integration without the address pressure, at the cost of the indirection an overlay adds. Plan the networking mode deliberately, as it is hard to change later.
Identity with Entra ID
AKS integrates with Microsoft Entra ID (formerly Azure AD) for both cluster access (Entra users and groups mapped to Kubernetes RBAC) and workload identity (Microsoft Entra Workload ID federates a Kubernetes ServiceAccount to an Entra identity so Pods reach Azure resources without secrets — the familiar federation pattern). Managed add-ons cover monitoring, policy, and the like. The rough edges are mostly the usual ones: getting the Entra-to-RBAC mapping and networking mode right up front.
Azure CNI Overlay — Pods get overlay IPs, not VNet addresses — avoids VNet IP exhaustion while keeping integration. The modern default.
kubenet (legacy) — older, simpler routing mode being phased out; fewer features.
- Assuming the free control-plane tier comes with an uptime SLA — production needing one should use the paid tier.
- Running workloads on the system node pool and letting app load threaten cluster add-ons.
- Picking the networking mode carelessly; it is hard to change after the cluster exists.
- Misconfiguring Entra integration and locking users out or falling back to stored Azure secrets.
- Treating version-sensitive AKS details as fixed instead of checking current Azure docs.
- Choose the paid control-plane tier when you need a financially-backed SLA; free tier otherwise.
- Separate system and user node pools so application load can't starve cluster services.
- Prefer Azure CNI Overlay to avoid VNet IP exhaustion; decide the mode up front.
- Use Entra Workload ID for Pod-to-Azure access rather than stored secrets.
- Map Entra users/groups to RBAC carefully and document it.
Knowledge Check
What is the catch with the AKS free control-plane tier?
- It runs the control plane best-effort with no financially-backed SLA; production needing one should pick Standard
- It ships without a functioning API server endpoint, so kubectl and Helm clients cannot connect to the cluster at all
- It caps every cluster at a single node with no cluster autoscaler allowed
- It blocks managed add-ons such as Container Insights and Azure Policy
How does Azure CNI Overlay help versus consuming VNet IPs directly?
- Pods get overlay IPs, avoiding VNet address exhaustion while keeping integration
- It removes the CNI plugin entirely and lets the kubelet route Pod traffic itself
- It transparently encrypts all Pod-to-Pod traffic with mTLS by default
- It runs Pods serverlessly with no underlying nodes
How do AKS Pods access Azure resources without stored secrets?
- Microsoft Entra Workload ID federates a ServiceAccount to an Entra identity
- Azure client secrets are baked into the node OS image at build time on each node
- By borrowing the system node pool's credentials that run CoreDNS
- They are blocked from reaching any Azure resource endpoints
You got correct