AKS vs Azure Container Apps
AKS and Azure Container Apps both run containerised workloads, but they serve different audiences. AKS is a full Kubernetes platform for teams who need direct cluster control. Container Apps is a managed application platform that happens to use containers — it hides Kubernetes entirely and focuses on the developer experience. Choosing between them is primarily a question of how much Kubernetes you actually need.
What each platform provides
AKS gives you a fully functional Kubernetes cluster with a managed control plane. You define Kubernetes resources — Deployments, Services, Ingress, ConfigMaps, Secrets, PersistentVolumeClaims, StatefulSets, and any Custom Resources. You manage node pools, configure networking (Azure CNI, kubenet), install Ingress controllers, set up autoscaling, and manage upgrades. The Kubernetes API is fully accessible via kubectl and the Azure CLI.
Azure Container Apps is a platform for deploying containerised applications without any Kubernetes knowledge. You provide a container image, configure environment variables, set scaling rules (HTTP concurrency, KEDA event sources), and Azure manages everything else. There is no kubectl, no YAML manifests for Kubernetes primitives, and no cluster management. The unit of deployment is a Container App, not a Kubernetes Deployment.
Head-to-head comparison
| Dimension | AKS | Azure Container Apps |
|---|---|---|
| Kubernetes API access | Full — kubectl, Helm, CRDs, admission webhooks | None — Container Apps API only |
| Operational complexity | High — node pools, upgrades, networking, RBAC | Low — no cluster management required |
| Scale to zero | Possible with KEDA (pods to zero); nodes still billed | Yes — full scale to zero, zero cost when idle |
| HTTP scaling | HPA with KEDA HTTP addon (requires setup) | Built-in HTTP concurrency-based scaling |
| KEDA support | Yes — install and configure manually | Yes — built-in, configure via Container Apps API |
| Dapr integration | Install as AKS extension; manage yourself | First-class built-in toggle |
| Networking control | Full — Network Policies, Ingress, service mesh, private cluster | Good — VNet integration, internal/external ingress, custom domains |
| StatefulSets / persistent volumes | Yes — full StatefulSet support | Limited — ephemeral volumes; Azure Files mount via volume |
| Multi-container pods | Yes — any pod topology | Yes — sidecar containers supported |
| GPU nodes | Yes — GPU node pools supported | No |
| Control plane cost | Free (Standard tier) | No separate control plane concept |
| Node/compute billing | Pay for node VMs; Spot node pools for savings | Per vCPU-second + GiB-second (Consumption); Dedicated plans available |
Scaling model differences
Container Apps scaling is designed for simplicity. You specify a minimum replica count (can be 0 for scale-to-zero), a maximum, and a scaling rule. Supported scaling rules include HTTP concurrent requests, Azure Queue depth, Service Bus queue depth, Kafka lag, and any KEDA scaler. Azure manages all scaling mechanics without any Kubernetes HPA or KEDA configuration files.
AKS scaling requires configuration of the Kubernetes Horizontal Pod Autoscaler (for CPU/memory-based scaling) or KEDA (for event-driven scaling), plus the Cluster Autoscaler for node-level scaling. Getting all three working correctly together — ensuring pods scale down before nodes, preventing premature scale-down, and avoiding pod scheduling failures during scale-up — requires careful configuration and testing.
For teams new to container orchestration, Container Apps scaling is significantly simpler to implement correctly. For teams with existing Kubernetes expertise who need fine-grained control over scaling behaviour, AKS provides the full configuration surface.
Cost comparison
Container Apps Consumption profile (East US):
- vCPU: $0.000024/vCPU-second (first 180,000 free/month)
- Memory: $0.000003/GiB-second (first 360,000 free/month)
- Requests: $0.40 per million HTTP requests
For a microservice running at 0.5 vCPU and 1 GiB, active 50% of the time in a month (1,296,000 active seconds), the cost is approximately: 648,000 vCPU-seconds × $0.000024 = $15.55 + 1,296,000 GiB-seconds × $0.000003 = $3.89. Total: ~$19.44/month.
The equivalent AKS deployment needs the microservice’s pod to be scheduled on a node. A Standard_B2s node pool node (~$35/month) can run 4–6 such pods. The AKS cost for this service is therefore ~$6–9/month (its share of node cost) — cheaper than Container Apps at sustained utilisation. But if the service is idle for 30% of the month, Container Apps charges nothing during idle periods while the AKS node bills continuously.
Container Apps Dedicated plan (Consumption + Dedicated workload profiles) allows you to run Container Apps on dedicated compute while still benefiting from the simpler Container Apps API. This is a middle path between pure Consumption billing and AKS node management — useful for workloads with predictable resource requirements and consistent throughput.
When AKS is the right choice
- You need direct Kubernetes API access for CRDs, admission webhooks, or custom controllers
- Workloads require StatefulSets with persistent volume claims and stable network identity
- You need GPU nodes for machine learning inference or training workloads
- Service mesh (Istio, Linkerd) is required for advanced traffic management and mTLS
- Multiple teams deploy to the same cluster with Kubernetes-native multi-tenancy (namespaces, resource quotas)
- You are running workloads that need to be portable to other Kubernetes platforms
When Container Apps is the right choice
- Your team does not have Kubernetes expertise and does not want to acquire it
- Workloads are containerised microservices or API services without complex StatefulSet requirements
- Scale-to-zero cost savings matter — Container Apps Consumption billing at zero is genuinely zero
- You want Dapr integration without the operational overhead of installing and managing it
- Event-driven workloads using KEDA scalers that would require significant AKS configuration to replicate
- Speed of deployment matters — a Container App can go from image to HTTPS endpoint in under 10 minutes
Common mistakes
- Choosing AKS because it sounds more “production-ready.” Container Apps runs on production AKS clusters managed by Microsoft with a 99.95% SLA. It is production-ready for the workload types it supports. Choosing AKS for the perception of seriousness rather than specific capability requirements adds operational overhead with no benefit.
- Trying to access kubectl on Container Apps. Container Apps does not expose the Kubernetes API. If your deployment process or operational runbook depends on kubectl, you cannot use Container Apps and must use AKS.
- Assuming Container Apps is always cheaper than AKS. At sustained high utilisation with multiple services, AKS node VMs can be more cost-efficient than Container Apps per-second billing. Model the cost for your specific workload profile before choosing based on pricing assumptions.
- Running stateful databases or message brokers on Container Apps expecting persistent local storage. Container Apps volumes are ephemeral by default. Persistent data must use Azure Blob Storage, Azure Files mounts, or external managed databases. Containers that write to local storage will lose data when replicas restart.
Summary
- AKS exposes the full Kubernetes API and is appropriate for teams with Kubernetes expertise who need CRDs, StatefulSets, service mesh, or GPU nodes. Container Apps hides Kubernetes and is appropriate for teams who want managed container hosting without cluster management.
- Container Apps scales to genuine zero with zero billing during idle periods. AKS pods can scale to zero with KEDA but node VMs continue billing.
- Container Apps has first-class KEDA and Dapr integration requiring no setup. AKS supports both but requires manual installation and configuration.
- For sustained high utilisation at scale, AKS node VMs can be more cost-efficient. For spiky or variable workloads, Container Apps Consumption billing is typically cheaper.
Frequently asked questions
Does Azure Container Apps use Kubernetes internally?
Yes. Container Apps runs on AKS clusters managed by Microsoft, but the Kubernetes API is not exposed. You interact with the Container Apps API only. This means you cannot run kubectl commands, deploy Helm charts, or use Kubernetes CRDs on Container Apps. The Kubernetes layer is an implementation detail.
What is Dapr and does it work with AKS?
Dapr (Distributed Application Runtime) is a sidecar-based framework that provides service discovery, state management, pub/sub messaging, and observability for microservices. Container Apps has first-class Dapr integration — you enable it with a toggle and configure components via the Container Apps API. AKS can also run Dapr but you install and manage it yourself as a Kubernetes extension.
How does Container Apps pricing compare to AKS?
Container Apps Consumption profile charges $0.000024/vCPU-second and $0.000003/GiB-second, with a free tier of 180,000 vCPU-seconds and 360,000 GiB-seconds per month. AKS charges nothing for the control plane but you pay for the underlying node VMs. For small workloads, Container Apps is typically cheaper. At large scale with high utilisation, AKS node VMs become more cost-efficient than Container Apps per-second billing.