"I want to run an app on Azure. But Container Apps, AKS, App Service, Functions, Container Instances… which should I choose?" — Azure's container/app platforms have many options, and a great many people stall here. Get the choice wrong and operational load and cost change several-fold.
This article, faithful to the official comparison document on Microsoft Learn, organizes the five options on the axes of operational load, scale, cost, and lock-in, and shows "which to choose for which requirement" with a decision flow. I've run serverless containers (Fargate) in production on AWS and operated a B2B SaaS with 221 APIs. From that experience, I can say the selection axes are isomorphic even when the cloud changes. For production operations of Azure Container Apps itself, see the Azure Container Apps production-operations guide.
Conclusion: choose in 30 seconds
| Your requirement | What to choose |
|---|---|
| Run general containers, microservices, jobs without K8s ops | Azure Container Apps |
| Directly access the Kubernetes API / control plane (CRD/Operator/DaemonSet) | Azure Kubernetes Service (AKS) |
| Website / web API-centric (code or container) | Azure App Service |
| The functions model (triggers + bindings) fits | Azure Functions |
| Low-level one-off container where you assemble scaling/LB/certificates yourself | Azure Container Instances (ACI) |
When unsure, Azure Container Apps. The official docs also state
many teams prefer to start building container microservices with Azure Container Apps.(compare-options). Because it erases the biggest cost — server management (labor).
The five options: the official positioning
Azure Container Apps — a serverless container/microservices platform
Azure Container Apps enables you to build serverless microservices and jobs based on containers. (— compare-options)
Its characteristic is being built on top of Kubernetes, Dapr, KEDA, and Envoy. It provides service discovery, traffic splitting, event-driven scaling (including scale-to-zero), jobs, and even Azure Functions execution as managed. And the decisive deliberate cut —
Azure Container Apps doesn't provide direct access to the underlying Kubernetes APIs. If you require access to the Kubernetes APIs and control plane, you should use Azure Kubernetes Service.
It doesn't directly expose the Kubernetes API. This is not a constraint but a value. No kubectl, no CRDs, no Helm needed. Even with zero Kubernetes ops knowledge, you get a managed experience based on Kubernetes best practices.
Azure Kubernetes Service (AKS) — fully managed Kubernetes
AKS supports direct access to the Kubernetes API and can run any Kubernetes workload. (compare-options). There are two models.
- AKS Standard: the cluster is in your subscription, and configuration/operation is your responsibility.
- AKS Automatic: a more hands-off, production-ready model where Azure pre-configures and manages node management, scaling, security defaults, and upgrades.
If you need the Kubernetes control plane itself — you want to define custom resources with CRDs, run an Operator, need a DaemonSet that runs one per node, or want a specific CNI/storage driver — AKS is the right answer.
Azure App Service — PaaS for web apps
Azure App Service provides fully managed hosting for web applications including websites and web APIs. (compare-options). You can deploy code or containers, and it's optimized for web apps. If you "want to publish a single web app/API in the shortest path" or "it's not a flock of microservices," App Service is the most natural.
Azure Functions — serverless FaaS
Azure Functions is a serverless Functions-as-a-Service (FaaS) solution. It's optimized for running event-driven applications using the functions programming model. (compare-options). Triggers (HTTP, queue, timer) and bindings (declaratively connecting input/output) are the core of productivity. If the model of "trigger a function on an event and bind it to a data source" fits, Functions. Note that Azure Functions can also run on a Container Apps environment (the two aren't exclusive).
Azure Container Instances (ACI) — a low-level one-off container
It can be thought of as a lower-level "building block" option compared to Container Apps. (compare-options). Scaling, load balancing, and certificates are not provided.
For example, to scale to five container instances, you create five distinct container instances. (— compare-options)
It's material at the level of "if you want five instances, you make five yourself." The standard use is as ephemeral CI/CD processing, or as a building block called from another service (AKS's virtual nodes, etc.). ACI only when you want to assemble app-operations concepts yourself.
Comparison table: lined up on four axes
| Axis | Container Apps | AKS | App Service | Functions | ACI |
|---|---|---|---|---|---|
| Operational load | Low (managed) | High (K8s ops) | Low | Low | Mid |
| K8s API | ✕ (hidden) | ◎ (direct) | ✕ | ✕ | ✕ |
| Scale-to-zero | ◎ (HTTP/event) | △ (bring KEDA yourself) | △ (plan-dependent) | ◎ | ✕ (one-off) |
| Event-driven | ◎ (KEDA built-in) | △ (DIY) | △ | ◎ (triggers) | ✕ |
| Microservices | ◎ (Dapr/service discovery) | ◎ (free) | △ | △ | ✕ |
| Web-optimized | ○ | ○ | ◎ | △ | △ |
| Certificates/LB auto | ◎ | △ (build Ingress) | ◎ | ◎ | ✕ |
| GPU | ◎ (serverless GPU) | ◎ | ✕ | △ | ◎ |
| Learning cost | Low | High | Low | Mid | Low |
Decision flow
Q1. Need the Kubernetes API / control plane (CRD/Operator/DaemonSet/custom CNI)?
└ YES → AKS (if you need the control plane, it's the only choice here)
Q2. A single website/web API, not a flock of microservices?
└ YES → App Service (shortest path with web optimization)
Q3. Does the "function triggered by an event" model fit naturally?
└ YES → Azure Functions (triggers + bindings)
* There's also the option of placing it on an ACA environment via Functions on Container Apps
Q4. Low-level one-off processing where you want to assemble scaling/LB/certificates yourself?
└ YES → ACI (ephemeral CI/CD processing, etc.)
Q5. Anything else (general containers, microservices, jobs, event-driven)
└ → Azure Container Apps (the default answer)
Field decision axes: three perspectives not on the official table
① Operational load = the biggest hidden cost
At a startup or in solo development, can you spare people for AKS operations (node upgrades, CNI/Ingress/certificate management, CVE response) — in many cases, the answer is no. AKS is powerful, but operations need dedicated staff. Because Container Apps gives you "the goodness of Kubernetes as managed," it suits putting out production quality with a small team. AKS Automatic narrows that gap, but the point that "holding the control plane = bearing the responsibility" remains.
Guideline: unless there's a clear reason you need the Kubernetes API, start with Container Apps. When it's not enough, drop down to AKS (your container images run as-is). The reverse — "build it out on AKS from the start" — tends to be a YAGNI violation.
② Scale-to-zero and cost
For intermittent, low-traffic workloads (internal tools, webhook receivers, irregular APIs), Container Apps' scale-to-zero + free tier drastically lowers the cost (180,000 vCPU-seconds, 360,000 GiB-seconds, and 2 million requests per month are free). For App Service and AKS, "keeping at least one instance always running" is realistic, so you're billed even during idle time. In projects where cost weighs on the decision, this is the divide. For details, see the cost-design chapter (the production-operations guide).
③ For microservices, Dapr and service discovery
For a microservices configuration where multiple services intercommunicate, Container Apps' Dapr (service invocation, Pub/Sub, state management) and DNS-based service discovery pay off. You can do the same on AKS, but it requires introducing and operating a service mesh (Istio/Linkerd). Container Apps lets you call by app name within the same environment, so the cognitive load is low.
A mapping for those with AWS experience
Even when the cloud changes, the selection axes are isomorphic.
| Role | AWS | Azure |
|---|---|---|
| Serverless containers | ECS on Fargate / App Runner | Azure Container Apps |
| Managed Kubernetes | EKS / EKS Auto Mode | AKS / AKS Automatic |
| Web PaaS | Elastic Beanstalk / App Runner | App Service |
| FaaS (functions) | Lambda | Azure Functions |
| Low-level one-off container | ECS RunTask / Fargate task | Azure Container Instances |
Just as it was "when unsure, Fargate" on AWS, on Azure it's "when unsure, Container Apps." The deeper differences between ACA and Fargate (scale-to-zero, serverless GPU, Spot, isolation granularity) are summarized in Azure Container Apps vs AWS ECS on Fargate, an in-depth comparison.
Common misconceptions
- "For microservices, AKS is the only choice" → No. If you don't need the Kubernetes API, Container Apps is faster with Dapr/service discovery/traffic splitting as standard.
- "Container Apps is for small scale only" → No. With the Dedicated profile up to
D32(32 vCPU/128 GiB) and a maximum of 1,000 replicas, it withstands production scale. - "App Service and Container Apps are the same" → No. App Service is web-app-optimized; Container Apps is general containers + event-driven + jobs. Microservices and queue-driven workers are Container Apps' domain.
- "Functions or Container Apps" is exclusive → No. With Functions on Container Apps, you can place functions on an ACA environment.
Summary: if you don't need the control plane, Container Apps without hesitation
Azure's container/app platforms are largely split by "do you need the Kubernetes control plane." If you need it, AKS; if not — general containers, microservices, event-driven, jobs — Container Apps is the default answer. Web-only → App Service, functions model → Functions, low-level one-off → ACI.
What matters in selection is choosing not "the most feature-rich" but "the one with the minimum operational load relative to the requirements." To build fast, cheap, and safe with one-person × generative AI, the staged design — run on Container Apps first, and move only the parts that truly need the control plane to AKS — doesn't generate technical debt.
For Azure container-platform selection, production builds, and migration from AWS, contact me. For production-operations details, see the Azure Container Apps production-operations guide.