Azure Kubernetes Service (AKS) is Microsoft's managed Kubernetes. Azure operates the control plane (and historically offers it free, charging only for worker nodes), handling availability and upgrades while you run workloads on node pools. As with EKS and GKE, it is conformant Kubernetes, so manifests and tooling are portable across clouds.
What AKS manages
Azure runs the API server and control plane and provides one-click upgrades. Worker capacity comes as node pools (you can mix VM sizes and spot instances), with the cluster autoscaler adding and removing nodes, and a virtual-node option backed by Azure Container Instances for fast burst capacity. You still own workload design, scaling policies, and add-on lifecycle.
Azure integration
- Microsoft Entra ID (Azure AD) - cluster authentication and RBAC tied to corporate identity; workload identity lets pods access Azure resources without stored secrets.
- Azure CNI - pods on the VNet, integrating with Azure networking and network policies.
- Azure Monitor, Key Vault, and storage drivers - native observability, secrets, and persistent volumes.
Why data engineers meet it
AKS hosts Spark-on-Kubernetes, Airflow, and other data workloads for Azure-based teams, and workload identity is the clean way to let those pods reach ADLS, Key Vault, and Azure databases without embedded credentials. It pairs naturally with the rest of the Azure analytics stack (Synapse, Event Hubs, Databricks).
AKS vs EKS vs GKE
The three managed Kubernetes services are close cousins; the choice follows your cloud and identity. AKS's draws are tight Entra ID integration and the no-charge control plane, making it the default for Azure-centric organizations. The Kubernetes you run is standard, so the real decision is where the rest of your data and identity already live.