Azure Container Services Compared: ACI vs Container Apps vs AKS

Azure has three main ways to run containers, and choosing wrongly costs you either months of unnecessary complexity or a monthly bill several times larger than it needed to be.

A rough analogy. ACI is a rental scooter: get on, go, get off, pay for the minutes. Container Apps is a shuttle service that handles the route and the timetable. AKS is buying your own fleet, with the control and the maintenance obligations that implies.

Side by side

Container Instances

ACI is the shortest path to a running container. Hand Azure an image, say how much CPU and memory it needs, and it runs. No cluster, no nodes, no orchestrator.

Use it for a single container doing something short lived: batch processing, a CI build agent, a scheduled job, a quick prototype.

The billing model is the important part. You pay per second of execution, and nothing at all when nothing is running. That makes ACI excellent for work measured in minutes or hours and progressively worse for anything running continuously, because a container running all month at per second rates costs more than the equivalent always on service.

Provision a container in ACI to see how little there is between you and a running image.

Container Apps

Container Apps sits between the other two. It runs on Kubernetes underneath and Microsoft operates the cluster, so you get autoscaling, ingress, revision management, traffic splitting for blue green releases, and event driven scaling, without writing Kubernetes manifests.

Use it for microservices, APIs and event driven applications that need to scale on their own.

The property that changes the economics is scaling to zero. AKS always has at least one node running and billing. Container Apps can drop to no replicas, and idle costs nothing. There is also a monthly free grant of compute per subscription, which is large enough that genuinely small applications sometimes run at no compute cost at all.

Deploy a container app from a Docker Hub image is the half hour version.

One container is not the interesting case though. Containerising and deploying a multi container application is much closer to what you would actually run, including how the services find each other.

Azure Kubernetes Service

AKS gives you a managed control plane with worker nodes you size and pay for. In exchange you get the entire Kubernetes API: Helm, custom operators, service mesh, StatefulSets, the whole ecosystem.

Use it when you need fine grained orchestration control, run genuinely stateful workloads, need GPU scheduling, or have a team that already knows Kubernetes and standardises on it across clouds.

The cost structure is different in kind rather than degree. You pay for nodes, and nodes run whether or not anything is deployed on them. That gives AKS a monthly floor that the other two do not have, and it is why a small workload on AKS looks so expensive next to the alternatives.

If Kubernetes is unfamiliar, learn it somewhere cheaper than a production cluster. Driving a cluster with kubectl is the honest starting point.

Then inspect, create and debug a pod, because debugging is what the job actually consists of once the cluster exists.

How the costs actually compare

Rather than quoting rates that change, here is the shape of it, which does not.

For short lived work, ACI and Container Apps are both cheap and AKS is dramatically more expensive, because you are paying for idle nodes between jobs.

For a handful of always on services with modest traffic, Container Apps is usually cheapest by a wide margin. ACI becomes expensive because per second billing never pauses, and AKS is still paying its node floor.

Somewhere around fifteen to twenty always on services with steady traffic, AKS starts to win. The node floor stops being wasted capacity and becomes efficient packing, and the per service overhead of Container Apps adds up.

For GPU work, ACI handles bursts and AKS handles sustained training. Container Apps is not the tool.

Check current pricing in the calculator before committing, and model your actual workload shape rather than a headline rate, because the crossover depends far more on utilisation than on the per unit price.

Mistakes worth avoiding

Choosing AKS because it sounds more serious. Kubernetes complexity is consistently reported as a top operational burden by teams running it. If Container Apps meets your requirements, choosing it saves hundreds of hours a year in upgrades, tuning and debugging. That time is the real cost, not the compute.

Running long lived services on ACI. No autoscaling, no health probes, and a bill that only goes up. It is the right tool used wrongly.

Forgetting the free grant. Container Apps includes a monthly compute allowance per subscription. Small applications frequently sit inside it, which changes the comparison entirely for side projects and internal tools.

Leaving networking until later. All three integrate with VNets, and retrofitting network isolation onto a running deployment is far more painful than deciding up front.

Forgetting the registry. Whichever you pick, your images need somewhere to live, and that is a separate line item. Create and manage a container registry covers the basics including authentication, which is where most first deployments stall.

A decision order that works

1. Is it a batch job or a short task? ACI.
2. Do you need Kubernetes specific features, custom operators, StatefulSets, DaemonSets? AKS.
3. Do you need GPUs? ACI for bursts, AKS for sustained.
4. Anything else? Container Apps.

Container Apps covers the large majority of containerised workloads. Start there and move to AKS when you hit a specific limitation you can name.

Next steps

Deploy something to each. Start with ACI to see how little ceremony a container needs, build a real service on Container Apps, and get to Kubernetes when you have a reason. Container services appear throughout AZ-104, and the questions are usually about which service fits a described workload, which is exactly the judgement this article is trying to build.