1. What and Why

Before any YAML, the decision: what AKS actually is, what it removes from your plate, what it very deliberately leaves on it, and when reaching for it is the wrong instinct.

One sentence

Azure Kubernetes Service is a managed Kubernetes offering where Microsoft runs the control plane — API server, scheduler, controller manager, and etcd — in its own subscription, and you run the worker nodes in yours.

That's the entire bargain. Everything else in this topic is a consequence of it.

The problem before it existed

Kubernetes solved a real problem: you had containers, you had machines, and matching one to the other by hand didn't survive contact with failure. Kubernetes turned "run this" into a declared desired state and a set of controllers that reconcile toward it continuously. A node dies; the pods are rescheduled. A deployment changes; pods roll over in a controlled sequence. Nobody SSHes anywhere.

But running Kubernetes yourself meant running a distributed database. A self-managed cluster requires:

• etcd, replicated across an odd number of members, backed up, and restored correctly under pressure — a job most teams do exactly once badly.
• A PKI, with certificates for every component, all of which expire, several of which expire in a year, and one of which expiring quietly stops your cluster accepting new nodes.
• API server HA behind a load balancer, in more than one failure domain.
• An upgrade path across control plane and nodes, in the right order, with the right version skew, without dropping the workloads in between.

None of that is your product. AKS deletes all four items. Microsoft runs the control plane, rotates its certificates, backs up etcd, and gives you az aks upgrade for the control plane and a separate per-node-pool upgrade for the data plane. In the Free tier it charges nothing for it at all.

The analogy: AKS is a rented kitchen with the fire-suppression system, the gas supply, and the health inspection already handled. You still hire the chefs, buy the ingredients, and own the menu — and the chefs (your nodes) are the expensive part.

[Image Prompt: 2D minimalistic split diagram contrasting a self-managed Kubernetes cluster where the team owns etcd, certificates, and the API server against a managed AKS cluster where Microsoft owns those components and the team owns only the worker nodes, flat design, clean vector art style, white background]

What AKS does not do for you

This list matters more than the previous one, because it's where the expectations break.

• It does not run your nodes' operating system for you. Node images are patched by Azure and published regularly, but applying a node image upgrade is an operation you schedule (or delegate to an auto-upgrade channel). An un-upgraded node pool drifts.
• It does not keep you on a supported Kubernetes version. AKS supports roughly the current minor version and the two before it, each for about a year ⚠️ verify current support policy against current Azure docs. Fall off the end and you're on an unsupported cluster with no patches. The Premium tier's Long-Term Support extends this to about two years for a designated version — it buys time, not immunity.
• It does not size anything. Requests, limits, replica counts, node pool VM sizes, autoscaler bounds, PodDisruptionBudgets — all yours. Most AKS cost and reliability problems are sizing problems.
• It does not secure your workloads. Network policy is off unless you turn it on. Pod-level admission control is off unless you add the Azure Policy add-on or your own admission webhooks. Secrets in etcd are encrypted at rest by the platform, but a Kubernetes Secret is base64, not encryption, to anyone who can read it through the API.
• It does not give you an SLA on your application. The Standard-tier SLA covers API server availability. Your pods' availability is a function of your replica count, your zone spread, your disruption budgets, and your readiness probes.

Where it sits in the Azure catalogue

Azure sells at least five ways to run a container, and the decision is usually made badly. The short version:

Choose	When
App Service	It's a web app or API, one container or none, and you want a URL and a deployment slot
Azure Container Instances	You want one container to run and exit. A primitive, not a platform
Azure Container Apps	Microservices, event-driven work, HTTP APIs; you want KEDA autoscaling and scale-to-zero and you do not need the Kubernetes API
Azure Kubernetes Service	You need the Kubernetes API itself — operators, CRDs, DaemonSets, service mesh, GPU device plugins, existing Helm charts, or real portability
Virtual Machines / VMSS	Something rules containers out entirely — a licensed appliance, a kernel dependency, a lift-and-shift

The sharpest question to ask before choosing AKS: name the Kubernetes feature you need that Container Apps doesn't have. If you can name it — a CRD, an operator, a DaemonSet, hostNetwork, a mesh, a scheduler plugin — AKS is right. If you can't, you are about to buy a cluster to run three containers, and you will spend the next two years upgrading it.

Container Apps deserves the specific caveat that it is built on AKS internals (and on KEDA, Dapr, and Envoy). Choosing it is not choosing "less Kubernetes"; it's choosing Kubernetes that someone else operates the rest of.

The AWS analogue, and where it breaks

AKS ≈ EKS. Managed control plane, self-managed worker capacity, pluggable CNI, cluster autoscaler, IAM-for-pods. Most of the mental model transfers. Four places it doesn't:

1. Pricing shape. EKS charges per cluster-hour unconditionally. AKS's Free tier charges nothing for the control plane — which makes cluster sprawl cheaper to start and just as expensive to operate. The Free tier's lack of an SLA, not its price, is the reason to leave it.
2. The node resource group. AKS creates a second resource group (MC_*) in your subscription and owns the node scale sets, load balancer, and disks inside it. EKS has nothing equivalent — node groups appear as EC2 resources you manage. This is the single most surprising AKS structural fact and it has real consequences for locks, policy, tagging, and deletion.
3. Authorization is three-layered. EKS bridges IAM into Kubernetes RBAC (historically via the aws-auth ConfigMap, now access entries). Azure has Azure RBAC on the cluster resource, Kubernetes RBAC inside the cluster, and an optional Azure RBAC for Kubernetes Authorization mode that lets Azure role assignments govern in-cluster actions too. Which of those is in play changes the answer to "why can't I list pods".
4. Identity for pods. IRSA ≈ Microsoft Entra Workload ID, and the mechanism is genuinely similar (a projected service-account token federated to a cloud identity). But Azure's earlier answer, AAD Pod Identity, is retired, and a lot of surviving blog content still teaches it. If a tutorial mentions AzureIdentity CRDs, it is out of date.

When not to reach for it

• One application, one team. Container Apps. The cluster is overhead you'll pay forever.
• No named owner for upgrades. This is the disqualifier. An AKS cluster is a subscription to ongoing work: a minor-version upgrade roughly every few months, node image upgrades more often than that, and add-on deprecations in between. Without an owner, the cluster silently ages into an unsupported, unpatchable liability.
• Cost-sensitive and idle-heavy. Nodes bill continuously. A cluster that serves ten requests an hour costs the same as one serving ten thousand, unless you've done real work with the cluster autoscaler or node autoprovisioning — and even then, the system node pool never reaches zero.
• Running managed-service replacements in-cluster. PostgreSQL, Kafka, Redis, and object storage all have Helm charts and all have Azure managed equivalents. Choosing the chart means choosing to own backup, failover, patching, and storage performance. Occasionally right; usually a bad trade made for the wrong reason (a licence cost or a portability principle) and regretted during an incident.
• "We need containers" is the whole requirement. That's ACI or Container Apps.

What you should be able to do now

Explain to a colleague, without slides, that AKS rents you a control plane and sells you nodes; that the Kubernetes API is the reason to choose it and the reason it costs you people; and that the correct question when someone proposes AKS is "which Kubernetes feature do you need?"

---

Next: Core Concepts →

← Back to the Azure Kubernetes Service overview