Azure Kubernetes Service (AKS): Managed Kubernetes on Azure

Q: AKS or Azure Container Apps?

Choose Container Apps for simplicity — serverless containers with KEDA-based scaling (including to zero) and no cluster to operate. Choose AKS when you want Kubernetes specifically: portability across clouds, the huge K8s ecosystem, service meshes, GitOps, or org standardization on Kubernetes. If you don't have a reason to want Kubernetes, Container Apps is the lower-effort choice.

Q: How do AKS pods access Azure resources securely?

Via Workload Identity — a pod's Kubernetes service account is federated to an Entra ID managed identity, giving it scoped access to Azure resources (Key Vault, storage) with no stored credentials. It's the AKS equivalent of EKS IRSA and the correct least-privilege pattern.

Q: Do I still manage servers with AKS?

You manage the node pools (VMs your pods run on) — sizing, scaling, and upgrades — plus workloads and add-ons. Azure manages the control plane. Virtual nodes (ACI) let some pods run serverlessly without VMs. So it's "managed control plane, you own the nodes and cluster contents" — not fully hands-off.

Azure Kubernetes Service (AKS)

Azure Kubernetes Service (AKS) is Microsoft Azure's managed Kubernetes offering. Azure runs and operates the Kubernetes control plane for you — highly available, patched, and (notably) free for the control plane itself — while you run workloads on node pools and use standard Kubernetes tooling. It's Azure's counterpart to AWS EKS and Google GKE: full, conformant Kubernetes without operating the hard part yourself.

AKS is the choice on Azure when you specifically want Kubernetes — its portability, ecosystem, and standard API — as opposed to Azure's simpler container option, Azure Container Apps. The trade is the same everywhere: Kubernetes' power and portability against its genuine operational complexity. For Microsoft-centric orgs, AKS integrates tightly with Entra ID, Azure networking, and Azure DevOps/monitoring tooling.

TL;DR

AKS runs the Kubernetes control plane for you (managed, HA, patched) — and the control plane is free; you pay only for the worker nodes.
Workloads run on node pools (VM-backed groups); you can mix pools (e.g., general + GPU + spot) and autoscale them.
Integrates with Azure: Entra ID for cluster auth and pod identity (workload identity), VNet networking (Azure CNI), Azure Monitor, and Key Vault for secrets.
Virtual nodes (on ACI) allow serverless burst capacity without provisioning VMs.
AKS vs Container Apps: AKS = full Kubernetes (portable, powerful, complex); Container Apps = simpler serverless containers (KEDA scaling, no cluster to manage). Choose AKS when you want Kubernetes specifically.
You still own cluster upgrades, node management, add-ons, and workloads — "managed control plane" isn't "fully managed everything."

Core Concepts

What AKS Manages

Azure operates the control plane — the complex, failure-prone part of running Kubernetes — at no charge (you pay only for worker nodes). You manage the nodes your pods run on and everything you deploy. This removes the biggest burden but leaves you owning upgrades, add-ons, and node lifecycle.

Node Pools

Worker capacity is organized into node pools — groups of identical VMs. AKS supports:

Multiple node pools — e.g., a general-purpose pool, a GPU pool for ML, a memory-optimized pool, each with different VM sizes.
Cluster autoscaler — adds/removes nodes based on pending pods.
Spot node pools — cheap, interruptible VMs for fault-tolerant/batch workloads (big cost savings).
Virtual nodes — burst pods onto Azure Container Instances (ACI) serverlessly, without provisioning VMs, for spiky demand.

Azure Integration

AKS wires Kubernetes into Azure primitives:

Identity: Entra ID integration for cluster authentication (users/groups log in with Entra ID), and Workload Identity to give pods scoped access to Azure resources (Key Vault, storage) via managed identities — the equivalent of EKS IRSA. No stored credentials in pods.
Networking: Azure CNI gives pods VNet IPs (first-class in your network); network policies and Azure Load Balancer / Application Gateway Ingress Controller handle traffic.
Storage: Azure Disk (block) and Azure Files (shared) CSI drivers for persistent volumes.
Observability: Azure Monitor for containers (Container Insights), or bring Prometheus/Grafana.
Secrets: Key Vault integration via the Secrets Store CSI driver.

GitOps and Tooling

AKS supports GitOps (Flux extension), integrates with Azure DevOps / GitHub Actions for CI/CD, and works with all standard Kubernetes tooling (Helm, operators, service meshes). The full CNCF ecosystem is available — that portability is a core reason to choose Kubernetes over Container Apps.

AKS vs Azure Container Apps

Azure's two main container options, and the key decision:

The guidance mirrors the EKS-vs-ECS decision: choose Container Apps if you just want to run containers on Azure simply (it handles scaling, including to zero, with no cluster to operate); choose AKS when you specifically want Kubernetes — for portability, the ecosystem (Helm, operators, service meshes, GitOps), or organizational standardization. Don't adopt AKS's complexity if Container Apps would serve.

Common Mistakes

Choosing AKS When Container Apps Would Do

Kubernetes is powerful but genuinely complex — upgrades, add-ons, node management, RBAC, networking. If your workload is a straightforward containerized app, Azure Container Apps removes all of that. Reach for AKS because you want Kubernetes specifically, not by default.

Node-Wide Permissions Instead of Workload Identity

Giving nodes broad access to Azure resources means every pod inherits it. Use Workload Identity (Entra ID) to scope Azure permissions per workload — the AKS security fundamental, equivalent to EKS IRSA.

Neglecting Upgrades

Kubernetes versions age out of support; AKS enforces upgrade windows. Falling behind means forced, riskier upgrades. Plan a regular cadence for the control plane, node pools, and add-ons — ongoing work, not set-and-forget.

Ignoring Spot and Autoscaling for Cost

Running fixed, oversized node pools 24/7 wastes money. Use the cluster autoscaler, spot node pools for interruptible workloads, and virtual nodes for burst — right-size to actual demand. See cloud costs.

VNet IP Exhaustion with Azure CNI

Azure CNI assigns VNet IPs to every pod, which can exhaust subnet address space in large clusters. Plan subnet sizing for pod density, or use CNI overlay/kubenet modes to conserve IPs. Same consideration as EKS's VPC CNI.

FAQ

AKS or Azure Container Apps?

Choose Container Apps for simplicity — serverless containers with KEDA-based scaling (including to zero) and no cluster to operate. Choose AKS when you want Kubernetes specifically: portability across clouds, the huge K8s ecosystem, service meshes, GitOps, or org standardization on Kubernetes. If you don't have a reason to want Kubernetes, Container Apps is the lower-effort choice.

Is the AKS control plane really free?

The standard control plane is free — you pay only for worker node VMs and associated resources. (A paid Standard/Premium tier adds an uptime SLA and longer support windows for the control plane, worth it for production.) This differs from AWS EKS, which charges a per-cluster control-plane fee.

How do AKS pods access Azure resources securely?

Via Workload Identity — a pod's Kubernetes service account is federated to an Entra ID managed identity, giving it scoped access to Azure resources (Key Vault, storage) with no stored credentials. It's the AKS equivalent of EKS IRSA and the correct least-privilege pattern.

AKS vs AWS EKS vs GKE?

All three are managed Kubernetes with the same core value (managed control plane, standard K8s). Differences: AKS's control plane is free (EKS charges per cluster); GKE is often considered the most "Kubernetes-native" given Google created Kubernetes; each integrates with its cloud's identity/networking. Choose by cloud. The workloads and tooling are portable across all three.

Do I still manage servers with AKS?

You manage the node pools (VMs your pods run on) — sizing, scaling, and upgrades — plus workloads and add-ons. Azure manages the control plane. Virtual nodes (ACI) let some pods run serverlessly without VMs. So it's "managed control plane, you own the nodes and cluster contents" — not fully hands-off.