AKS or App Service: which one should you use?
Kubernetes is a demanding machine to keep alive; AKS is the deal where Azure runs the demanding part for free and you pay only for the boxes your containers land on.
New to cloud? CAMPUX is a free, build-first course. Start here →
Running Kubernetes yourself means owning an etcd cluster, an API server, a scheduler, and the controllers that keep the whole thing honest — and keeping every one of them patched, backed up, and highly available at three in the morning. That is the tax people forget when they say they want Kubernetes. Azure Kubernetes Service takes that tax off your desk. Microsoft describes it plainly: when you create an AKS cluster, "Azure automatically creates and configures a control plane for you at no cost," and "you only pay for the AKS nodes that run your applications." That single sentence is most of what AKS is.
What AKS is
AKS is managed Kubernetes. You get a real, CNCF-certified Kubernetes cluster — the same API, the same kubectl, the same manifests you would run anywhere — but Azure operates the control plane on your behalf. The control plane is the brain: the API server that every command talks to, the etcd key-value store that holds the entire cluster's state, the scheduler that decides where things run, and the controllers that notice when a node dies and react. Azure runs all of it, monitors its health, and upgrades it, and it charges you nothing for that layer. What you pay for is the second half of the cluster: the nodes.
The brain is Azure's problem. The muscle is on your bill.
The control-plane and node-pool split
An AKS cluster has two halves, and knowing which side of the line a component sits on is the whole mental model. On Azure's side is the control plane — kube-apiserver, etcd, kube-scheduler, kube-controller-manager. You do not SSH into those; you cannot, and that is the point. On your side are the nodes: ordinary Azure VMs that run your containers, each carrying a kubelet and a container runtime. Nodes are grouped into node pools — a system pool that hosts cluster-critical pods like CoreDNS, and user pools that host your applications. You choose the VM size, the count, and the OS; those VMs are billed as standard VMs, reservation discounts and all. The node pools are the part you size, scale, patch, and pay for.
The "free" in AKS is specific: Azure operates the control plane at no charge on the Free tier, which supports up to 1,000 nodes. Your bill is the agent VMs, their disks, and their networking. If you want a financially backed uptime SLA on the control plane, the Standard tier adds a per-cluster management fee — but the default posture is a managed brain you do not pay for, attached to muscle you do.
How a workload gets onto a node
You do not place containers on machines by hand. You hand Kubernetes a desired state — "run three replicas of this image" — and the control plane makes it true. You kubectl apply a manifest; the API server writes it into etcd. The scheduler notices pods with no assigned node and picks one for each, matching the pod's CPU and memory requests against what each node has free. On the chosen node, the kubelet pulls the image and starts the container. If a node dies, a controller sees the gap and the scheduler places the missing pods elsewhere. That self-healing loop is the reason people accept Kubernetes at all — and with AKS the loop runs on a control plane you never had to build.
Where it fits, and where it does not
AKS is not the only way to run containers on Azure, and it is rarely the first one you should reach for. If you have a web app or an API and you want it deployed without thinking about clusters, App Service or Container Apps will get you there with a fraction of the operational surface. Reach for AKS when you genuinely need what Kubernetes gives you: fine-grained control over scheduling, a large fleet of microservices, an existing library of Helm charts, or portability across clouds because you are already speaking the Kubernetes API. Those are real needs. They are also specific ones.
Now for the honest part. AKS makes Kubernetes cheaper to run; it does not make Kubernetes simple. You still own the nodes, the upgrades, the networking model, the ingress, the RBAC, and the pile of YAML that describes all of it. Kubernetes is a lot of moving parts, and every one of them is a thing that can page you. If your team is three people shipping one service, that operational weight buys you almost nothing and costs you real hours. Pick AKS because you have outgrown the simpler options — not because the word looks good on an architecture diagram.
The takeaway
Azure Kubernetes Service is managed Kubernetes with the cost line drawn in a sensible place: Azure runs the control plane for free, and you pay for the nodes your pods land on. Microsoft owns the API server, etcd, and the scheduler; you own the node pools, the VM sizes, and the workloads. That split removes the hardest part of running Kubernetes but not the responsibility of running everything above the nodes. Choose it once you have outgrown Container Apps and genuinely need what Kubernetes gives you, and choose something plainer when you have not. The teams who run AKS well are the ones who counted the parts they would still have to carry before they ever signed up for the cluster.
Questions people also ask
Is Azure Kubernetes Service free?
Partly. Azure runs the AKS control plane for free on the default Free tier, and it charges you nothing to create or operate a cluster. What you pay for is the agent nodes: ordinary Azure VMs, their disks, and their networking. So the orchestration brain is free, but running any real workload on it is not. If you want a financially backed uptime SLA on the control plane, the Standard tier adds a small per-cluster fee.
What is the difference between AKS and App Service?
App Service is a managed place to run a web app or API where Azure hides the infrastructure entirely — you push code and it runs. AKS gives you a full Kubernetes cluster, which means far more control over scheduling, networking, and scaling, and far more to operate. App Service is the shorter path for a standard web workload. You reach for AKS when you have outgrown that and genuinely need Kubernetes.
Do you pay for the AKS control plane?
Not on the Free tier, which is the default. Azure creates, monitors, and upgrades the control plane — the API server, etcd, the scheduler, the controllers — at no cost, and that tier supports up to 1,000 nodes. You only start paying at the control-plane layer if you opt into the Standard tier for a 99.95 percent uptime SLA. Your normal bill is the agent nodes and their disks and networking.
Is Kubernetes hard to learn?
Yes, and AKS does not change that. AKS removes the work of running the control plane, but you still own the nodes, the upgrades, the networking model, the ingress, the RBAC, and a large amount of YAML. Kubernetes has many moving parts and each one can page you. Expect a real learning curve, and pick it only when a simpler service like App Service or Container Apps genuinely cannot do the job.
What is Azure Kubernetes Service used for?
AKS is used to run containerized applications on a managed Kubernetes cluster. It fits when you need fine-grained control over scheduling, a large fleet of microservices, an existing library of Helm charts, or portability across clouds because you already speak the Kubernetes API. Azure operates the control plane and you operate the node pools that run your pods. For a single standard web app, a simpler container service is usually the better tool.