What is AKS, and when would you choose it over App Service?

Azure Kubernetes Service (AKS)

AKS is Azure's managed Kubernetes service. Azure runs the control plane (API server, scheduler, etcd) for you, and you run the workloads: you package your app as containers, describe the desired state in Kubernetes manifests, and Kubernetes keeps it running, scaled, and healthy across a pool of VMs called nodes.

What you get and what you still own

Azure manages	You manage
Control plane (HA, patching, upgrades on request)	Node pools: sizes, zones, upgrade cadence
Integration with Entra ID, ACR, Azure Monitor, Key Vault	Deployments, Services, Ingress, autoscaling configuration
Optional node image patching and auto-upgrade channels	Network design, policies, and security hardening
	Observability, cost control, and application-level resilience

AKS Automatic is a newer mode that takes over more of this (node provisioning, scaling, networking defaults, and security baselines), which reduces the operational burden. Standard mode gives full control but more responsibility. Check the current docs for what each mode includes.

Core concepts

• Cluster: control plane plus one or more node pools.
• Node pool: a group of identical VMs (system pools for cluster components, user pools for your apps). You can mix sizes, GPU nodes, spot nodes, and Linux/Windows.
• Pod: the smallest deployable unit, one or more containers sharing a network namespace.
• Deployment: declares the desired number of pod replicas and handles rolling updates.
• Service and Ingress: stable internal addressing and HTTP routing into the cluster.
• HPA / KEDA / cluster autoscaler: scale pods on metrics or events, and nodes to fit the pods.
• Namespaces, RBAC, network policies: isolation and access control between teams and workloads.
• Workload identity: lets pods authenticate to Azure services via Entra ID with no stored secrets (the Kubernetes counterpart of managed identity).

When to choose AKS over App Service

Choose AKS when you have a concrete need that App Service can't meet well:

• Many services, one platform. Dozens of microservices with different scaling and release needs, where Kubernetes' scheduling and bin-packing are efficient and consistent.
• Kubernetes-native tooling is a requirement. Helm, operators, custom resource definitions, Argo CD/Flux GitOps, Istio or other service meshes, admission controllers like OPA/Gatekeeper or Kyverno.
• Complex deployment topologies. Sidecars, init containers, daemonsets, stateful sets, multi-container pods, and canary or blue/green rollouts with traffic splitting at the mesh or ingress layer.
• Fine-grained control over scheduling, node types (GPU, high-memory, spot), pod placement, resource limits, and network policy.
• Portability. You want the same deployment model across Azure, other clouds, and on-premises (with Azure Arc or other distributions), and want to limit platform lock-in.
• Specialized workloads. ML training and inference, batch/HPC jobs, event-driven processing with KEDA, or software that ships as a Helm chart or operator (databases, message brokers, observability stacks).
• You have the skills. A platform or DevOps team that already knows Kubernetes and can own cluster operations.

Choose App Service when:

• You have one or a few APIs or web apps and want to ship fast.
• The team is small or doesn't have Kubernetes expertise.
• Deployment slots, built-in TLS, Easy Auth, and managed scaling cover your needs.
• You want low operational overhead and a predictable, per-plan cost.
• You don't need anything beyond "run this app, scale it, keep it healthy."

Side-by-side

	App Service	AKS
Abstraction	Deploy an app	Run a cluster
Ops burden	Low	Moderate to high (lower with Automatic)
Skills needed	Azure and your framework	Kubernetes, containers, networking
Packaging	Code or container	Containers only
Time to first deploy	Minutes	Hours to days (cluster, ingress, identity, CI/CD)
Zero-downtime releases	Slots and swap	Rolling updates, canary via ingress or mesh
Ecosystem	Azure-native	Entire Kubernetes ecosystem
Cost shape	Per plan	Per node (paid when idle) plus platform effort
Best for	Typical APIs and web apps	Large, complex, or Kubernetes-standardized platforms

The trade-offs to be honest about

• AKS is a platform, not an app host. Ingress, certificates, secrets, observability, policy, upgrades, and cost management are all things you assemble and maintain.
• Cluster upgrades are real work. Kubernetes releases frequently, and versions go out of support. You need an upgrade process and test environment.
• Idle capacity costs money. Nodes run whether or not they're busy, so you need good bin-packing and autoscaling to be cost-effective.
• Security is shared. Pod security, network policies, image scanning, RBAC, and supply-chain controls are your responsibility.
• Complexity can outweigh benefits for a single API. Many teams adopt AKS for flexibility they never use.

The middle ground

Azure Container Apps runs containers on Kubernetes under the hood, with KEDA scaling, revisions with traffic splitting, Dapr, and scale to zero, but without exposing the cluster. If your reason for considering AKS is "I have containers and want autoscaling and microservices," Container Apps often fits without the operational cost. Move to AKS when you hit its limits (need for custom operators, daemonsets, node-level control, or specific networking).

A minimal AKS deployment

az aks create --name my-aks --resource-group my-rg \
  --node-count 3 --zones 1 2 3 \
  --enable-managed-identity --enable-oidc-issuer --enable-workload-identity \
  --attach-acr myacr --network-plugin azure --network-plugin-mode overlay

az aks get-credentials --name my-aks --resource-group my-rg
kubectl apply -f deployment.yaml

A production setup also typically includes an ingress controller (NGINX or Application Gateway for Containers), cert-management, Azure Monitor/Container Insights, Key Vault secrets via the CSI driver, network policies, pod disruption budgets, autoscaling, and a GitOps or CI/CD pipeline.

Decision rule

• One to a handful of APIs, small team → App Service.
• Containers, microservices, but you want minimal ops → Container Apps.
• Many services, platform team, Kubernetes ecosystem or portability needs, custom scheduling or workloads → AKS.

Start with the simplest platform that meets today's requirements. Because App Service, Container Apps, and AKS can all run the same container image, containerizing your app keeps the door open to move later when you have a concrete reason.