Azure AKS: A Practical Guide

By Khimananda Oli | Last reviewed: August 2026

Deploying managed Kubernetes often introduces hidden complexity around networking, identity, and cost that basic tutorials ignore. This Azure AKS: A Practical Guide addresses those production gaps by focusing on secure defaults, scalable architecture, and operational reality rather than hello-world demos. Whether you are migrating from on-prem or starting fresh, getting the foundation right prevents expensive rework later. For teams already standardizing on Microsoft's ecosystem, aligning your cluster strategy with broader Azure DevOps workflows ensures your infrastructure scales alongside your delivery pipelines.

How do you provision a secure Azure AKS cluster correctly?

The most common mistake I see when reviewing Azure AKS deployments is treating the cluster as an isolated island rather than an integrated Azure resource. Secure provisioning starts before you run a single az aks create command. You must define your networking model, identity strategy, and node topology upfront because changing them post-deployment often requires a full cluster rebuild.

Choose Azure CNI Overlay over Kubenet

In 2026, Azure CNI Overlay is the recommended default for most production workloads. Unlike Kubenet, which relies on user-defined routes and has scalability limits around 400 nodes per subnet, CNI Overlay assigns pod IPs from a separate CIDR space that is encapsulated within the node's VNET. This gives you native VNET integration without exhausting subnet IP addresses. It also supports Windows nodes and advanced network policies natively.

az aks create \
  --resource-group rg-aks-prod \
  --name aks-prod-eastus \
  --network-plugin azure \
  --network-plugin-mode overlay \
  --pod-cidr 10.244.0.0/16 \
  --service-cidr 10.0.0.0/16 \
  --dns-service-ip 10.0.0.10 \
  --enable-private-cluster \
  --api-server-authorized-ip-ranges "YOUR_OFFICE_IP/32" \
  --node-resource-group rg-aks-prod-nodes \
  --generate-ssh-keys

Enforce Private Cluster Access

Never expose the Kubernetes API server to the public internet unless absolutely necessary. The --enable-private-cluster flag removes the public endpoint entirely. Access the API through a private endpoint in your VNET, Azure Cloud Shell with managed identity, or a jump box in a peered network. If you must allow specific external IPs during migration, use --api-server-authorized-ip-ranges but plan to remove it once private connectivity is established.

Separate System and User Node Pools

Always create at least two node pools: one dedicated system pool for critical cluster components (CoreDNS, metrics-server, kube-proxy) and separate user pools for application workloads. Taint the system pool with CriticalAddonsOnly=true:NoSchedule to prevent business applications from being scheduled there. This isolation ensures that app resource exhaustion never takes down cluster DNS or monitoring.

How does Azure AKS handle identity and secret management?

Identity management is where many AKS deployments fail security audits. Stop using long-lived service principal credentials immediately. In 2026, Azure Workload Identity is the standard for granting pods access to Azure resources like Key Vault, Storage, or SQL Database without embedding secrets in environment variables.

Configure Workload Identity Federation

Workload Identity uses OIDC federation between your AKS cluster and Azure Entra ID. Each Kubernetes service account maps to a specific Azure Managed Identity. When a pod mounts the projected token volume, the Azure SDK exchanges the K8s token for an Entra access token transparently.

1. Enable OIDC issuer and workload identity on the cluster: az aks update --enable-oidc-issuer --enable-workload-identity
2. Create a user-assigned managed identity and federated credential linking it to your K8s namespace/service account
3. Annotate your service account with the Azure client ID: azure.workload.identity/client-id: <managed-identity-client-id>
4. Add the label azure.workload.identity/use: "true" to pods that should inject the token

Integrate Key Vault via CSI Driver

For secrets that must remain in Key Vault rather than K8s Secrets, use the Azure Key Vault Provider for Secrets Store CSI Driver. This mounts vault entries as files or syncs them to K8s Secrets automatically. Combined with Workload Identity, pods authenticate to Key Vault without any connection strings or passwords stored in the cluster. Enable auto-rotation so updated vault values propagate to running pods without restarts.

How do you configure autoscaling and cost optimization in AKS?

Cost overruns in AKS typically stem from three issues: over-provisioned nodes, missing vertical scaling, and ignoring spot instances. Address each layer independently. Horizontal Pod Autoscaler (HPA) adjusts replica counts based on metrics, Vertical Pod Autoscaler (VPA) right-sizes container requests, and Cluster Autoscaler adds or removes nodes based on pending pods. These must be tuned together — HPA alone will not reduce your bill if nodes stay provisioned with idle capacity.

Enable KEDA for Event-Driven Scaling

Standard HPA only reacts to CPU/memory. Most real workloads scale based on queue depth, HTTP request rate, or custom metrics. KEDA (Kubernetes Event-driven Autoscaling) is now a first-class AKS add-on. Install it via az aks addon enable --addon keda and define ScaledObjects that trigger scaling based on Azure Service Bus queue length, Event Hub lag, or Prometheus queries. This eliminates both over-provisioning during quiet periods and under-provisioning during traffic spikes.

Use Spot Node Pools for Fault-Tolerant Workloads

Spot VMs offer 60–90% discounts compared to pay-as-you-go pricing. Create a dedicated spot node pool for batch processing, CI runners, or stateless services that can tolerate eviction. Never put databases, ingress controllers, or system components on spot nodes. Configure pod disruption budgets and graceful shutdown handlers so evictions don't cause data loss or downtime.

az aks nodepool add \
  --resource-group rg-aks-prod \
  --cluster-name aks-prod-eastus \
  --name spotbatch \
  --priority Spot \
  --spot-max-price -1 \
  --eviction-policy Delete \
  --vm-size Standard_D4s_v5 \
  --min-count 0 \
  --max-count 10 \
  --labels workload-type=batch \
  --taints spot=true:NoSchedule

Right-Size with VPA Recommendations

Deploy VPA in recommendation-only mode first (--vpa-recommender-only). Let it collect usage data for 1–2 weeks, then review suggested CPU/memory requests. Apply these recommendations manually or enable auto-mode for non-critical namespaces. Right-sizing typically recovers 20–40% of wasted spend without any architectural changes. Combine this with Azure Advisor insights for additional VM family recommendations.

What are the key differences between AKS networking models?

Networking is the most consequential decision in AKS deployment because it affects performance, security, and scalability permanently. Understanding the trade-offs prevents costly migrations later.

For new deployments in 2026, choose Azure CNI Overlay unless you have a specific requirement for pods to hold real VNET IPs directly. Classic CNI consumes one VNET IP per pod, which causes subnet exhaustion at scale and complicates multi-cluster peering. Overlay avoids this entirely while maintaining full VNET routability through encapsulation. If you're migrating from Kubenet, plan a blue-green cutover rather than attempting in-place conversion.

How do you maintain and upgrade AKS clusters safely?

Operational excellence separates demo clusters from production systems. AKS abstracts control plane management but still requires disciplined upgrade planning, monitoring, and backup strategies. Treat your cluster as livestock, not pets — every component should be replaceable through automation.

Implement Planned Maintenance Windows

Define maintenance windows explicitly using az aks maintenanceconfiguration add. Specify allowed days, hours, and duration for both OS patching and Kubernetes version upgrades. Without this, Azure may apply updates during peak business hours. For Nepal-based teams serving local users, schedule windows during late-night IST/NPT overlap to minimize impact. Always test upgrades on a staging cluster first using identical node configurations.

Automate Backup with Velero

AKS does not back up etcd or persistent volumes automatically. Deploy Velero with the Azure plugin to snapshot PVs and export cluster manifests to Azure Blob Storage. Schedule daily backups for production namespaces. Test restores quarterly — untested backups are just hopes. For compliance frameworks like SOC 2 or ISO 27001, documented restore procedures are mandatory evidence.

Monitor with Azure Monitor Container Insights

Enable Container Insights during cluster creation (--enable-addons monitoring). This provides pre-built dashboards for node health, pod restarts, resource saturation, and controller manager latency. Supplement with Prometheus/Grafana for custom application metrics. Set alerts on node NotReady conditions, high eviction rates, and failed deployments. Integrate alerts with your incident response workflow — if you're learning about outages from users instead of monitors, your observability stack is broken.

Moving Forward with Azure AKS

This Azure AKS: A Practical Guide covers the foundations that determine whether your Kubernetes platform accelerates delivery or becomes a maintenance burden. Start with secure defaults: private API access, Workload Identity, CNI Overlay, and separated node pools. Layer in cost controls through KEDA, spot instances, and VPA right-sizing. Automate backups and define maintenance windows before your first production deployment. If you need help designing an AKS architecture that meets your specific compliance, performance, or budget requirements, reach out to discuss your infrastructure needs. For teams building CI/CD alongside their clusters, review how to deploy to AKS with Azure Pipelines for integrated delivery workflows. Remember: if it isn't automated, observable, secure, and audit-ready, it isn't production-ready.