How to Set Up Azure AKS: 13 Steps, 90 Min [2026]

Azure Kubernetes Service turns a multi-hour cluster bring-up into a single terminal command, and in 2026 it remains one of the three managed Kubernetes platforms every backend team eventually evaluates alongside Amazon EKS and Google Kubernetes Engine. Microsoft’s own pricing page confirms the tier structure that makes AKS practical for staged rollouts: a free control plane for prototyping, a $73-a-month Standard tier with a financially backed SLA for production traffic, and a $438-a-month Premium tier that buys two years of long-term support on a pinned Kubernetes version.

This tutorial builds a real AKS cluster from a blank Azure subscription. You’ll install the CLI, provision the control plane, deploy a sample workload, package it with Helm, wire up autoscaling, lock down access with Microsoft Entra ID, and turn on Azure Monitor. Budget about 90 minutes for all 13 steps on a fresh subscription. By the end you’ll have a cluster you can tear down in one command or keep running as the base for a production workload.

·

Google · Preferred Sources

Don't miss new tech stories on Google

Add Tech Insider once in the Google app and our stories appear in your news suggestions.

Add Now

What Is Azure Kubernetes Service and Why It Matters in 2026

Azure Kubernetes Service is Microsoft’s managed offering for running Kubernetes, the open-source container orchestrator that schedules, scales, and heals containerized workloads. AKS handles the parts of Kubernetes operations that used to eat up a platform team’s week: patching the API server, running etcd, rotating certificates, and coordinating control plane upgrades. You still create and manage the worker nodes (unless you pick AKS Automatic, more on that below), but Microsoft owns the control plane’s uptime, security patching, and version support.

Three things changed for AKS heading into the back half of 2026. First, Microsoft finished rolling the platform onto a 12-month support policy for every generally available Kubernetes version, with Kubernetes 1.36 reaching GA on AKS in June 2026 and 1.33 through 1.35 still fully supported. Second, AKS Automatic matured into a real alternative to hand-tuned clusters: it provisions nodes, configures networking, and applies Microsoft’s baseline security settings for a flat $116.80 per cluster per month, aimed at teams who want production-ready defaults without reading the entire AKS cluster architecture docs. Third, node autoprovisioning, a Karpenter-inspired scheduler that right-sizes nodes automatically, kept expanding to more regions, though you should check current release notes before leaning on it for a production workload.

AKS makes sense when your workloads already run in containers, your team wants Kubernetes-native tooling (Helm, kubectl, the CNCF ecosystem) instead of a proprietary PaaS, and you’re either already on Azure or need Microsoft Entra ID for identity. It makes less sense for a single small container that barely needs autoscaling. Azure Container Apps or a plain App Service instance will get you there faster with less to operate. If you’re coming from this site’s general Kubernetes setup tutorial, this guide picks up where that one leaves off: it goes straight to a managed cloud cluster instead of minikube or kind.

The underlying appeal hasn’t changed since Kubernetes became a CNCF graduated project: the API, the object model, and tools like Helm behave the same whether the control plane sits on Azure, on a laptop, or on bare metal in a data center. That portability is why AKS, EKS, and GKE keep showing up together in the same evaluation spreadsheets. Learning AKS well transfers almost entirely to the other two, and vice versa, because the differences live in identity, networking, and billing rather than in how you write a Deployment manifest.

Prerequisites: Tools, Versions, and Azure Requirements

You don’t need prior Kubernetes experience to follow along, but you should be comfortable running commands in a terminal and reading YAML. Here’s what to have in place before Step 1.

Requirement	Version / Detail	Why You Need It
Azure subscription	Pay-As-You-Go, or a free trial with starting credit	Hosts the resource group and every billed resource in this tutorial
Azure CLI	2.60 or later (run az upgrade if unsure)	Creates and manages the AKS cluster from your terminal
kubectl	Within one minor version of your cluster’s Kubernetes version	Talks to the Kubernetes API server once the cluster exists
Helm	Helm 4.x (Helm 3.x still works but is approaching end of support)	Packages and deploys the sample app as a reusable chart
Azure role	Contributor on the subscription or target resource group	Lets your account create AKS, networking, and identity resources
Terminal	macOS, Linux, or WSL2 on Windows	Runs every az, kubectl, and helm command in this guide

One more note on cost: everything in this tutorial fits inside typical free-trial credit if you tear it down at the end (Step 13 covers that). Left running, a two-node Standard tier cluster on general-purpose VMs plus the $73 monthly control plane fee will land somewhere in the $150 to $220 per month range depending on region and VM size. Keep that in mind if you’re testing on a personal card.

Step 1: Install and Configure the Azure CLI

Everything in this tutorial runs through the az command. Install it for your platform, then sign in and confirm the CLI can see your subscription.

# macOS
brew update && brew install azure-cli

# Windows (PowerShell)
winget install -e --id Microsoft.AzureCLI

# Linux (Debian/Ubuntu)
curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash

# Confirm the install and sign in
az version
az login

# If you have more than one subscription, set the right one
az account list --output table
az account set --subscription "YOUR_SUBSCRIPTION_ID"

az login opens a browser window for authentication. On a headless server, add the --use-device-code flag instead and follow the printed instructions. Once signed in, az account show should print the subscription you intend to bill. Double-check this before moving on. Creating resources against the wrong subscription is the single most common setup mistake in this whole process, and it’s easy to fix now and annoying to fix later.

Step 2: Create a Resource Group

Every AKS cluster lives inside an Azure resource group, the container Azure uses to group related resources for billing and lifecycle management. Creating a dedicated group for this tutorial means Step 13’s cleanup is a single command instead of a hunt through your subscription.

az group create \
  --name rg-aks-tutorial \
  --location eastus

Swap eastus for a region closer to you or your users. Run az account list-locations --output table to see the full list. Pick a region with good VM availability for the size you plan to use, since not every SKU is offered everywhere, a detail that trips people up in Step 4.

Step 3: Understand AKS Pricing Tiers Before You Provision

AKS charges for the control plane separately from the worker nodes, and picking the wrong tier is the most expensive mistake you can make in this tutorial. Microsoft splits cluster management into four options, confirmed directly from the current Azure Kubernetes Service pricing page.

Tier	Control Plane Cost	SLA	Node Limit	Best For
Free	$0 (pay only for VMs)	No formal SLA (99.5% internal goal)	1,000 (not recommended past ~10 nodes)	Learning, demos, dev/test
Standard	$73 per cluster/month	Financially backed API server SLA	Up to 5,000	Production workloads
Premium (LTS)	$438 per cluster/month	Financially backed SLA + 2-year LTS	Up to 5,000	Regulated workloads on a pinned Kubernetes version
Automatic	$116.80 per cluster/month	Financially backed API + pod readiness SLA	Up to 5,000	Teams that want Microsoft to manage nodes too

Compute is billed on top of whichever tier you pick, priced per vCPU per month by VM category: roughly $7.05 for general-purpose, $10.96 for compute-optimized, $11.16 for memory-optimized, and $32.29 for GPU-accelerated vCPUs, according to Microsoft’s published rates. For this tutorial, the Standard tier is the right call. Free tier clusters get throttled control plane performance and no uptime guarantee, which makes even a beginner tutorial feel sluggish once you start applying manifests.

Worth knowing: AWS and Google price their control planes almost identically to Azure. All three landed on $0.10 per cluster per hour for standard support and $0.60 per cluster per hour for extended or long-term support, a convergence that’s easy to verify by comparing the AKS, EKS, and GKE pricing pages side by side. The section near the end of this guide breaks that comparison down further.

Step 4: Create Your First AKS Cluster

This is the command that actually stands up the control plane and a default system node pool. It takes several minutes to complete, Azure is provisioning VMs, configuring networking, and bootstrapping Kubernetes components behind the scenes.

az aks create \
  --resource-group rg-aks-tutorial \
  --name aks-tutorial-cluster \
  --tier standard \
  --node-count 2 \
  --node-vm-size Standard_D2s_v3 \
  --network-plugin azure \
  --enable-managed-identity \
  --generate-ssh-keys

A few flags worth explaining. --tier standard pulls in the SLA discussed in Step 3. --network-plugin azure selects Azure CNI, which assigns each pod a routable IP from your virtual network (the alternative, kubenet, uses node IPs plus NAT and works fine for smaller clusters but complicates certain networking scenarios later). --enable-managed-identity replaces the older service-principal authentication model, so Azure rotates credentials for you instead of leaving that on your plate. Standard_D2s_v3 is a reasonable general-purpose size for a first cluster: 2 vCPUs and 8 GiB of RAM per node, enough to run several small pods without hitting resource pressure immediately.

If the command fails with a quota or SKU availability error, that’s almost always a regional capacity issue rather than something wrong with your syntax. The troubleshooting section further down covers the fix.

For anything beyond a tutorial, add --zones 1 2 3 to spread nodes across availability zones within the region. That’s a one-flag decision at creation time that’s painful to retrofit later, since it affects how node pools and attached disks get provisioned. A single-zone cluster survives a VM failure fine, but not a full datacenter-level outage in that zone, which is the scenario zonal spread actually protects against.

Step 5: Connect kubectl to the Cluster

With the cluster running, pull its credentials into your local kubeconfig so kubectl knows where to send commands.

# Install kubectl if you don't already have it
az aks install-cli

# Merge cluster credentials into ~/.kube/config
az aks get-credentials \
  --resource-group rg-aks-tutorial \
  --name aks-tutorial-cluster

# Confirm the connection
kubectl get nodes
kubectl cluster-info

kubectl get nodes should list two nodes in Ready status within a minute or two of cluster creation finishing. If you manage multiple clusters, kubectl config get-contexts shows every context currently merged into your kubeconfig, and kubectl config use-context aks-tutorial-cluster switches between them without re-running get-credentials.

Step 6: Add a User Node Pool for Application Workloads

The node pool AKS created in Step 4 is a system pool, reserved for core cluster components like CoreDNS and the metrics server. Running your own application pods there works, but it competes with those system pods for capacity and makes node upgrades riskier. Add a separate user pool for your workloads instead.

az aks nodepool add \
  --resource-group rg-aks-tutorial \
  --cluster-name aks-tutorial-cluster \
  --name userpool \
  --node-count 2 \
  --mode User \
  --node-vm-size Standard_D4s_v3

# Confirm both pools exist
az aks nodepool list \
  --resource-group rg-aks-tutorial \
  --cluster-name aks-tutorial-cluster \
  --output table

This split matters more as clusters grow. A production AKS cluster commonly runs a small, stable system pool alongside one or more user pools sized and scaled independently around the actual application load, which is also what makes the autoscaling setup in Step 10 effective instead of just scaling everything indiscriminately. Sizing the user pool is mostly arithmetic: total the CPU and memory requests of the pods you expect to run at once, add headroom for the autoscaler to work with, and pick the smallest VM size that clears that bar. Oversized nodes waste money on unused capacity, undersized ones force the scheduler to spread a handful of pods across more nodes than the app actually needs.

Step 7: Deploy Your First Application

Time to run something. Create a namespace to keep this tutorial’s resources isolated, then deploy Microsoft’s public AKS sample image, a small web app built for exactly this kind of walkthrough.

kubectl create namespace demo-app

Save this as deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-aks
  namespace: demo-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: hello-aks
  template:
    metadata:
      labels:
        app: hello-aks
    spec:
      containers:
        - name: hello-aks
          image: mcr.microsoft.com/azuredocs/aks-helloworld:v1
          ports:
            - containerPort: 80
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 250m
              memory: 256Mi

Apply it and watch the pods come up:

kubectl apply -f deployment.yaml
kubectl get pods -n demo-app --watch

Notice the resources block. Setting explicit requests and limits isn’t optional busywork, it’s what lets the Kubernetes scheduler place pods sensibly and what lets the cluster autoscaler in Step 10 know when it actually needs another node. Skip it and you’ll eventually hit the resource-pressure problem covered in the pitfalls section below.

Step 8: Expose the App with a Service and Ingress

A running pod isn’t reachable from outside the cluster until you expose it. For a quick test, a LoadBalancer service provisions a public Azure Load Balancer with an external IP.

apiVersion: v1
kind: Service
metadata:
  name: hello-aks
  namespace: demo-app
spec:
  type: LoadBalancer
  ports:
    - port: 80
      targetPort: 80
  selector:
    app: hello-aks

kubectl apply -f service.yaml
kubectl get service hello-aks -n demo-app --watch

Give it a minute or two for EXTERNAL-IP to move from <pending> to an actual address, then open it in a browser to see the sample app respond. A LoadBalancer service is fine for one app, but provisioning a separate public IP for every microservice gets expensive and hard to manage fast. For anything with more than a couple of services, install an ingress controller (ingress-nginx or the Azure Application Gateway Ingress Controller are the two most common choices on AKS) and route traffic through a single entry point using host- and path-based rules instead.

ingress-nginx is the faster path if you just want one shared entry point without touching Azure-specific networking resources yet. It installs like any other Helm chart, the workflow Step 9 covers in more depth:

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update
helm install ingress-nginx ingress-nginx/ingress-nginx \
  --namespace ingress-basic \
  --create-namespace \
  --set controller.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-health-probe-request-path"=/healthz

That gives every future service a shared external IP and lets you route by hostname or path with an Ingress object instead of a new LoadBalancer service each time.

Step 9: Package the App with Helm

Applying raw YAML works for a tutorial, but it doesn’t scale to real environments where you need the same app deployed with different settings across dev, staging, and production. That’s the problem Helm solves. As the project’s own documentation puts it, “Helm uses a packaging format called charts” (Helm Project), and “charts are packages of pre-configured Kubernetes resources” (Helm Project) that you can template, version, and roll back as a single unit.

# Scaffold a new chart
helm create hello-aks-chart

# Point the chart at the sample image (edit values.yaml, or override on install)
helm install hello-aks ./hello-aks-chart \
  --namespace demo-app \
  --set image.repository=mcr.microsoft.com/azuredocs/aks-helloworld \
  --set image.tag=v1 \
  --set service.type=LoadBalancer

# Check what's running
helm list -n demo-app

Once the chart exists, upgrades and rollbacks become one-line operations instead of hand-editing manifests:

# Bump the replica count and ship it
helm upgrade hello-aks ./hello-aks-chart \
  --namespace demo-app \
  --set replicaCount=5

# Something broke? Roll back to the previous release
helm rollback hello-aks 1 -n demo-app

Helm 4, released in November 2025 as the project’s first major update in six years, is the current line and the one you should default to for anything new. Helm 3 keeps receiving security patches through February 2027, so existing Helm 3 charts aren’t an emergency to migrate, but new charts should target Helm 4 templates. If you publish charts publicly, look at Helm’s own documentation on OCI registry support, which lets you push and pull charts from the same container registries (including Azure Container Registry) you already use for images, instead of running a separate chart repository.

Step 10: Configure Autoscaling

A fixed node count works for a tutorial, not for real traffic. AKS supports two complementary autoscaling mechanisms: the Horizontal Pod Autoscaler, which adds and removes pod replicas based on CPU or memory usage, and the cluster autoscaler, which adds and removes nodes when pods can’t be scheduled.

# Enable the cluster autoscaler on the user pool
az aks nodepool update \
  --resource-group rg-aks-tutorial \
  --cluster-name aks-tutorial-cluster \
  --name userpool \
  --enable-cluster-autoscaler \
  --min-count 2 \
  --max-count 6

# Autoscale pods based on CPU usage
kubectl autoscale deployment hello-aks \
  --namespace demo-app \
  --cpu-percent=70 \
  --min=3 \
  --max=10

Microsoft has also been extending node autoprovisioning (NAP), a Karpenter-based alternative that picks VM sizes automatically instead of scaling a pre-defined pool. It’s worth evaluating once it’s fully available in your region, but check the current AKS release notes before betting a production workload on it, since rollout and feature parity have continued to shift through 2026. For most teams starting out, the cluster autoscaler paired with the Horizontal Pod Autoscaler above covers the common case without extra moving parts.

Step 11: Lock Down Access with Microsoft Entra ID and RBAC

By default, anyone with the cluster admin credentials has full access to everything in it. That’s fine for a solo tutorial, not fine for a team. AKS integrates with Microsoft Entra ID (the identity platform formerly known as Azure AD) so you can grant Kubernetes permissions through the same accounts and groups you already manage.

# Enable Azure RBAC and Entra ID integration on an existing cluster
az aks update \
  --resource-group rg-aks-tutorial \
  --name aks-tutorial-cluster \
  --enable-azure-rbac \
  --enable-aad

# Grant a user or group read-only access, scoped to the cluster
az role assignment create \
  --assignee-object-id "" \
  --assignee-principal-type "Group" \
  --role "Azure Kubernetes Service RBAC Reader" \
  --scope "$(az aks show --resource-group rg-aks-tutorial --name aks-tutorial-cluster --query id -o tsv)"

Azure ships several built-in Kubernetes RBAC roles beyond Reader, including Writer, Admin, and Cluster Admin, each scoped to what a team actually needs rather than defaulting everyone to full access. Combine this with Azure Policy for AKS (covered in the advanced tips section) if you need to enforce guardrails like blocking privileged containers or requiring specific labels, on top of who can do what.

One distinction worth remembering: --enable-aad turns on Entra ID authentication (proving who you are), while --enable-azure-rbac turns on Azure’s authorization layer (deciding what you’re allowed to do once authenticated). You can run Entra ID authentication with native Kubernetes RBAC objects instead of Azure RBAC if your team already manages Roles and RoleBindings through GitOps, but most teams starting fresh find Azure RBAC easier to audit since role assignments show up in the same portal as every other Azure permission.

Step 12: Monitor the Cluster with Azure Monitor

You can’t fix what you can’t see. Azure Monitor’s container insights add-on collects node and pod metrics, container logs, and cluster events into a Log Analytics workspace without installing a separate observability stack.

az aks enable-addons \
  --resource-group rg-aks-tutorial \
  --name aks-tutorial-cluster \
  --addons monitoring

# Tail logs for a specific pod the traditional kubectl way, too
kubectl logs -n demo-app -l app=hello-aks --follow

Once enabled, Container Insights shows up in the Azure Portal under your cluster’s Monitoring blade, with prebuilt views for node CPU and memory pressure, pod restarts, and controller health. If your team already standardized on Prometheus and Grafana, AKS doesn’t force a choice: you can run the managed Prometheus add-on alongside or instead of Container Insights and keep your existing dashboards.

Step 13: Clean Up and Tear Down

Because every resource in this tutorial lives inside one resource group, cleanup is a single command instead of deleting the cluster, node pools, load balancer, disks, and public IPs one at a time.

# Deletes the cluster and every resource inside the group
az group delete --name rg-aks-tutorial --yes --no-wait

The --no-wait flag returns your terminal immediately instead of blocking until deletion finishes, which can take several minutes. Run az group show --name rg-aks-tutorial afterward. Once it errors out with a “not found” message, everything is gone and billing has stopped.

What This Tutorial’s Cluster Actually Costs

It helps to see the pricing tiers from Step 3 turned into a real monthly number instead of an abstract table. The cluster this tutorial builds runs a two-node system pool on Standard_D2s_v3 and a two-node user pool on Standard_D4s_v3, on the Standard tier, with a LoadBalancer service in front of it. Here’s roughly what that costs left running for a full month, using Microsoft’s published rates from Step 3.

• Control plane (Standard tier): $73 per month, fixed regardless of node count
• System pool compute: 2 nodes x 2 vCPUs x roughly $7.05 per general-purpose vCPU, about $28 per month
• User pool compute: 2 nodes x 4 vCPUs x roughly $7.05 per general-purpose vCPU, about $56 per month
• Load balancer and public IP: typically $20 to $30 per month depending on region and data processed

Add it up and you’re looking at roughly $180 to $190 a month before storage, egress, or Azure Monitor’s Log Analytics ingestion costs, which bill separately based on data volume. That number drops fast if you scale the user pool down after testing, or shoots up fast if you forget a cluster is running. Either way, it’s worth checking against the Azure Kubernetes Service calculator linked from the pricing page before you commit a workload to a specific node size, since regional pricing does shift the total by a meaningful margin.

The Complete Project: A Production-Ready AKS Starter Stack

Strung together, the 13 steps above produce a cluster with a clear separation of concerns: a system pool running core Kubernetes components, a user pool running your application, an app deployed and packaged as a Helm chart instead of loose YAML, autoscaling active at both the pod and node level, Entra ID controlling who can touch the cluster, and Azure Monitor watching all of it. That’s a genuinely reasonable starting point for a small production service, not just a learning exercise.

From here, the natural next additions are a GitOps controller (see the advanced tips section) so deployments happen through pull requests instead of local helm upgrade commands, an ingress controller with TLS termination instead of a bare LoadBalancer, and Azure Container Registry attached to the cluster so images never have to leave Microsoft’s network to reach your nodes. Attach ACR with a single command once you’re ready: az aks update --resource-group rg-aks-tutorial --name aks-tutorial-cluster --attach-acr <your-acr-name>.

Common Pitfalls When Setting Up Azure Kubernetes Service

• Picking the Free tier for anything beyond a demo. No SLA and a throttled control plane make the whole cluster feel slow once you’re applying more than a handful of manifests, and you’ll end up migrating to Standard anyway.
• Running application pods on the system node pool. They’ll compete with CoreDNS, metrics-server, and other core components for CPU and memory, and make node upgrades more disruptive than they need to be. Add a user pool in Step 6 and use it.
• Skipping resource requests and limits. Without them, the scheduler can’t make good placement decisions and the cluster autoscaler doesn’t know when to add capacity, so pods sit in Pending during a traffic spike instead of triggering a scale-up.
• Choosing a VM size your region doesn’t stock. Not every SKU is available in every region, and quota limits vary too. Check availability before you’re mid-deployment, not after az aks create fails twenty minutes in.
• Ignoring Kubernetes version end-of-life dates. AKS enforces a 12-month support window per version. Falling behind means an eventual forced upgrade on Microsoft’s timeline instead of yours, often with less testing time than you’d like.
• Exposing every microservice with its own LoadBalancer service. Each one provisions a separate public IP and load balancer rule, which adds up in cost and in operational surface area. Consolidate behind a single ingress controller once you’re past a service or two.

Troubleshooting: Common AKS Errors and Fixes

Most AKS problems fall into a handful of repeatable categories. Here’s what to check first.

Error or Symptom	Likely Cause	Fix
SubscriptionNotRegistered for Microsoft.ContainerService	The resource provider isn’t registered on a newer or unused subscription	Run az provider register --namespace Microsoft.ContainerService and retry
az aks create fails with a SKU or quota error	The chosen VM size isn’t available in that region, or you’re over your vCPU quota	Try a different --node-vm-size, a different --location, or request a quota increase in the Azure Portal
kubectl commands hang or time out	Credentials weren’t merged, or a local firewall/VPN is blocking the API server	Re-run az aks get-credentials, check authorized IP ranges if you enabled API server restrictions
Pods stuck in Pending	Insufficient CPU/memory on existing nodes, or no matching node for taints/tolerations	Run kubectl describe pod <name> to see the scheduling event, then scale the node pool or fix the resource request
ImagePullBackOff	Wrong image tag, private registry auth missing, or ACR not attached	Verify the image reference, then attach ACR with az aks update --attach-acr
LoadBalancer service stuck on <pending> EXTERNAL-IP	Public IP quota exhausted, or a networking/subnet misconfiguration	Check public IP quota in the portal and confirm the subnet has free address space
Nodes show NotReady	Kubelet or CNI plugin failure, often from an NSG blocking required ports	Run kubectl describe node <name> and check outbound rules on the node’s network security group
Helm install fails: “rendered manifests contain a resource that already exists”	A resource with the same name exists but wasn’t created by Helm	Delete the conflicting resource, or import it into Helm’s release tracking before reinstalling
Cluster upgrade hangs on a node drain	A PodDisruptionBudget is blocking eviction, or there’s no surge quota available	Review PodDisruptionBudgets for that namespace and confirm you have quota for surge nodes during upgrade

Advanced Tips for Running AKS in Production

Once the basics are working, a few upgrades separate a tutorial cluster from something you’d actually put a customer-facing app on.

• Adopt GitOps instead of manual deploys. Point ArgoCD or Flux at your Helm charts so every change ships through a pull request with an audit trail, instead of someone running helm upgrade from a laptop. This site’s ArgoCD vs Flux comparison covers the tradeoffs between the two if you haven’t picked one yet.
• Consider AKS Automatic for greenfield projects. At $116.80 per cluster per month with nodes, networking, and baseline security handled for you, it can be cheaper in engineering time than hand-tuning a Standard tier cluster, even though the sticker price per cluster is higher.
• Move to Azure CNI Overlay for large clusters. Standard Azure CNI assigns every pod a routable VNet IP, which can exhaust address space at scale. The overlay mode keeps pod IPs out of the VNet entirely and scales further without a networking redesign.
• Turn on Azure Policy for AKS. It enforces guardrails like blocking privileged containers or requiring specific resource limits cluster-wide, backed by the open-source Gatekeeper/OPA project, so bad manifests get rejected before they ever run.
• Use spot node pools for fault-tolerant batch work. Spot VMs cost meaningfully less than standard pricing in exchange for possible eviction, a fair trade for CI runners, batch jobs, or anything that tolerates a restart.
• Pin your upgrade channel deliberately. AKS supports automatic upgrade channels (rapid, stable, patch, node-image) instead of defaulting to manual upgrades. Pick one that matches your team’s testing cadence rather than leaving it unset.

AKS vs EKS vs GKE: Choosing the Right Managed Kubernetes

The honest answer is that the three major managed Kubernetes platforms have converged more than they’ve diverged. All three now charge the same $0.10 per cluster per hour for standard-tier control planes and $0.60 per cluster per hour for extended or long-term support, verified directly against each provider’s current pricing page.

Feature	AKS	EKS	GKE
Free tier	Free tier with no control plane charge (no SLA)	No always-free cluster, billed from the first hour	$74.40/month credit per billing account, covering roughly one cluster
Standard control plane	$73/cluster/month	$73/cluster/month	$73/cluster/month (flat fee, all modes)
Extended/LTS support	$438/cluster/month, 2-year LTS	$438/cluster/month, 12-month extended support	$438/cluster/month equivalent extended track
Identity integration	Microsoft Entra ID	AWS IAM	Google Cloud IAM
Packaging ecosystem	Helm, kubectl, standard CNCF tooling	Helm, kubectl, standard CNCF tooling	Helm, kubectl, standard CNCF tooling

Since the packaging and orchestration layer is identical Kubernetes and Helm on all three, the real decision usually comes down to where your identity, networking, and existing infrastructure already live rather than a feature gap in the Kubernetes layer itself. Teams already deep in Entra ID and Azure DevOps get more value from AKS than they’d get from re-plumbing that same access model on EKS or GKE, and the reverse is just as true for AWS- or GCP-native shops. If you’re weighing this site’s separate Amazon EKS tutorial or Google Kubernetes Engine setup guide against this one, that’s the question to answer first, not raw pricing.

Frequently Asked Questions

Is Azure Kubernetes Service free to use?

The Free tier has no control plane management charge, so you only pay for the underlying VMs, storage, and networking your nodes consume. Production traffic should use the Standard tier instead, which costs $73 per cluster per month and adds a financially backed uptime SLA that the Free tier doesn’t include.

How long does it take to create an AKS cluster?

Typically five to ten minutes from running az aks create to nodes showing Ready in kubectl get nodes. Larger node counts, non-default networking, or add-ons enabled at creation time can push that closer to fifteen minutes.

Do I need to know Kubernetes before learning AKS?

Basic familiarity helps but isn’t required. If terms like pods, deployments, and services are new to you, work through this site’s Kubernetes setup tutorial first, since it covers those core objects on a local cluster before you pay for anything in the cloud.

What’s the difference between AKS Standard and AKS Automatic?

Standard tier gives you full control over node pools, VM sizes, and networking, and you manage all of it yourself. AKS Automatic, priced at $116.80 per cluster per month, provisions and manages nodes for you and applies Microsoft’s baseline security configuration, trading some flexibility for less operational overhead.

Can I run AKS without Azure CNI?

Yes. Kubenet is the alternative networking option and uses node IPs with NAT instead of assigning each pod a routable VNet IP. It’s simpler for small clusters but has more limitations around network policy and peering than Azure CNI, so most production clusters use Azure CNI or its overlay variant.

How do I upgrade Kubernetes versions on AKS without downtime?

AKS performs upgrades one node at a time by default, cordoning and draining each node before moving to the next. Set a PodDisruptionBudget on your deployments so Kubernetes won’t drain more replicas than your app can tolerate at once, and pick an automatic upgrade channel that matches how often your team can validate a new version.

Does Helm work the same way on AKS as on any other Kubernetes cluster?

Yes. Helm talks to the standard Kubernetes API, so charts that work on EKS, GKE, or a local cluster work on AKS without modification. The only AKS-specific piece is where you store charts, and Azure Container Registry’s OCI support means you can host them in the same registry as your container images.

What happens to my data if I delete an AKS cluster?

Deleting the cluster removes its nodes, control plane, and any disks provisioned automatically for it. Persistent volumes backed by Azure Disks with a “Delete” reclaim policy are removed too, while volumes set to “Retain” survive the cluster and need to be cleaned up separately. Check your storage classes before running Step 13 if you have data you need to keep.