Azure Kubernetes Service (AKS) Overview

What AKS manages for you

Understanding the division of responsibility is the most important thing to grasp about AKS.

Microsoft manages:

• The Kubernetes control plane — API server, etcd, scheduler, controller manager
• Control plane high availability (99.95% SLA with Availability Zones)
• Control plane upgrades (you trigger them, Azure executes them safely)
• Control plane security patching

You manage:

• Worker nodes (Azure VMs) — sizing, count, OS patching
• Your workloads and their configuration
• Networking choices (CNI plugin, network policies)
• Storage configuration (persistent volumes)
• Access control and RBAC configuration

AKS significantly reduces operational burden but does not eliminate it. You still need to think about node sizing, upgrades, security, and cost.

How AKS pricing works

The control plane is free. You pay only for the resources your cluster uses:

• Worker nodes — the VMs in your node pool. A cluster with three Standard_D2s_v3 nodes costs the same as running three of those VMs directly.
• Uptime SLA — optionally pay ~$0.10/hour for a financially-backed 99.95% SLA on the API server. Without this, you get the same availability but no SLA commitment.
• Storage — persistent volumes backed by Azure Disks or Azure Files are charged at standard storage rates.
• Load balancers — if your services expose a public IP, you pay for Azure Load Balancer hours.
• Egress — data leaving Azure costs money. Traffic between AKS and the internet incurs egress charges.

AKS pricing tiers

AKS has three tiers for the control plane:

The Premium tier gives you access to Long Term Support (LTS) Kubernetes versions, which are supported for two years instead of the standard 12 months. This matters if you need to reduce how often you run major upgrades.

Key AKS features worth knowing

Azure Active Directory integration

AKS integrates with Azure AD (now called Microsoft Entra ID) for authentication. Instead of managing Kubernetes service accounts for humans, you use Azure AD users and groups. This means your existing identity infrastructure works in Kubernetes without extra setup.

Cluster autoscaler

When pods cannot schedule because nodes are full, the cluster autoscaler adds nodes. When nodes are underutilized, it removes them. This keeps your costs proportional to actual load.

Node auto-provisioning

A newer capability that goes further than the cluster autoscaler — it automatically selects the right VM size for pending pods rather than requiring you to pre-define node pool VM SKUs.

Spot node pools

Spot VMs cost up to 90% less than regular VMs but can be evicted with 30 seconds notice. AKS supports spot node pools for batch jobs and fault-tolerant workloads that can handle sudden termination.

KEDA (Kubernetes Event-driven Autoscaling)

AKS has built-in support for KEDA, which scales pods based on external event sources like queue length, HTTP request rate, or custom metrics — not just CPU and memory.

Azure Policy for Kubernetes

Enforce governance across your clusters using Azure Policy. Block pods that run as root, require resource limits, or enforce naming conventions — all without custom admission webhooks.

Creating an AKS cluster from the CLI

The fastest way to understand AKS is to create a cluster. You need the Azure CLI and kubectl installed.

# Log in to Azure
az login

# Create a resource group
az group create \
  --name my-aks-rg \
  --location eastus

# Create the AKS cluster (3 nodes, Standard_D2s_v3 VMs)
az aks create \
  --resource-group my-aks-rg \
  --name my-cluster \
  --node-count 3 \
  --node-vm-size Standard_D2s_v3 \
  --enable-managed-identity \
  --generate-ssh-keys

# Get credentials so kubectl works
az aks get-credentials \
  --resource-group my-aks-rg \
  --name my-cluster

# Verify connection
kubectl get nodes

The cluster creation takes 3–8 minutes. Once kubectl is configured, you can deploy workloads immediately.

AKS integrations with the Azure ecosystem

AKS is not isolated — it connects deeply to the Azure platform:

• Azure Container Registry (ACR) — attach an ACR to your cluster with one command and your nodes can pull private images without managing credentials
• Azure Monitor / Container Insights — automatic metrics and logs from every node and pod, visualized in Azure Portal
• Azure Key Vault — mount secrets from Key Vault directly into pods using the Secrets Store CSI driver
• Azure Managed Identities — give pods Azure IAM identities so they can call Azure APIs without embedding credentials
• Azure Virtual Network — clusters run inside a VNet, letting pods communicate with other Azure resources using private IPs
• Azure Application Gateway — acts as an ingress controller with built-in WAF and SSL termination

# Attach Azure Container Registry to an AKS cluster
az aks update \
  --resource-group my-aks-rg \
  --name my-cluster \
  --attach-acr my-registry-name

When AKS is the right choice

AKS is a good fit when:

• You are running multiple containerized services that need to communicate
• You need fine-grained control over scaling, networking, and deployment strategies
• Your team already knows Kubernetes or wants to invest in learning it
• You need to run workloads that require specific VM types, GPUs, or Windows containers
• You want workload portability across clouds or on-premises

AKS may be overkill when:

• You are running a single small application — Azure Container Apps or Azure App Service may be simpler
• You have no team expertise and cannot invest in learning Kubernetes
• You need to run containers for short-lived tasks only — Azure Container Instances may be cheaper

Availability zones and production readiness

For production, spread your cluster across Availability Zones so that a zone failure does not take down your entire cluster. AKS supports zone-spread at cluster creation time:

az aks create \
  --resource-group my-aks-rg \
  --name prod-cluster \
  --node-count 3 \
  --zones 1 2 3 \
  --tier standard \
  --enable-managed-identity \
  --generate-ssh-keys

With —zones 1 2 3, AKS spreads nodes across three Availability Zones. If one zone fails, two-thirds of your nodes remain available and the cluster continues operating.