Container Apps vs AKS: When to Pick Which (and Why I Pick Container Apps More Often Now)

Two years ago I'd default to AKS for any non-trivial workload. Today I start with Azure Container Apps and only graduate to AKS when I have a specific reason. Here's the shift in my thinking.

Container Apps gives you, for free

• Built-in Dapr (state, pub-sub, secrets, observability).
• KEDA-based scale-to-zero. Yes, zero. You're not paying for idle replicas.
• Managed ingress with automatic HTTPS, custom domains.
• Revisions for blue-green / canary without writing manifests.
• Workload profiles for GPU, memory-optimized, consumption.
• Per-second billing, no node-pool management.

Pick AKS when…

1. You need cluster-wide services Container Apps doesn't expose — e.g. a service mesh you've already standardized on, custom ingress controllers, operators.
2. You need DaemonSets or StatefulSets. Container Apps doesn't model these.
3. You need privileged containers or specific kernel modules.
4. You're running Kafka/Cassandra-style stateful workloads directly on the cluster.
5. Your team has deep Kubernetes ops investment already and re-tooling costs more than the savings.

Pick Container Apps when…

1. You have stateless HTTP/gRPC services. (Most workloads.)
2. Traffic is bursty or unpredictable — scale-to-zero is real money.
3. Your team doesn't want to be on call for the cluster, only the app.
4. You want Dapr without installing and maintaining it yourself.

The honest cost picture

An AKS Standard cluster has a $73/month control plane fee plus 2-3 B-series nodes minimum (~$60/mo). Container Apps charges only for vCPU/RAM seconds your apps actually run. For a workload that runs 4 hours a day, Container Apps is roughly 1/6 the cost.

The migration path

Most teams over-invest in AKS for workloads that would have been fine on Container Apps. The migration is usually painless: same Dockerfile, an azd template, and your env vars in a config map become Container Apps secrets. Worth piloting.