Containers in Azure: Your Options and How to Choose

The five container services in Azure

You will rarely need VM Scale Sets with manual Docker orchestration — that approach pre-dates AKS and Container Apps and has almost no good reason for new deployments. The real decision is between ACI, App Service, Container Apps, and AKS.

When to use Azure Container Instances

ACI is for disposable, job-like workloads. You create a container, it runs, it exits. ACI is not a platform for running services — it has no load balancing across replicas, no autoscaling, and no service discovery. Think of it as a managed Docker run command in the cloud.

Good ACI use cases: nightly batch processing jobs, data transformation pipelines, one-off migration scripts, CI/CD task runners, and testing a new container image quickly without setting up infrastructure. See Azure Container Instances for the full picture.

When App Service handles containers well

If you already have App Service experience and want to run a containerised web app or API, deploying a container to App Service is straightforward. You swap the runtime setting for a container image reference. Everything else — deployment slots, HTTPS, custom domains, managed identities, diagnostic logging — works identically to code-based App Service deployments.

App Service for containers makes sense when:

• You are running a single-container web application or API
• You want deployment slots for zero-downtime releases
• The team is already familiar with App Service and wants to avoid a new platform
• You need App Service’s built-in authentication middleware (Easy Auth)

App Service for containers does not support multiple containers as a unit (container groups/pods). For that, use Container Apps or AKS.

When Container Apps is the right choice

Azure Container Apps is the middle ground between ACI and AKS. It runs containerised microservices with automatic scaling, service-to-service networking, traffic splitting, and event-driven triggers — without requiring Kubernetes knowledge to operate.

Container Apps fits well when:

• You have multiple microservices that need to communicate internally
• Your service needs to scale to zero during off-hours and scale out quickly under load
• You want KEDA-powered event-driven scaling (scale based on Service Bus queue depth, HTTP traffic, custom metrics)
• You want Dapr integration for distributed application patterns (pub/sub, state management, service invocation)
• You need traffic splitting between container revisions for canary or blue-green deployments

Container Apps uses Kubernetes internally but hides the cluster management. You cannot access the underlying Kubernetes API. If you need direct kubectl access, custom Kubernetes operators, or cluster-level networking control, AKS is the appropriate choice instead.

When you actually need AKS

AKS is a managed Kubernetes service. It gives you a full Kubernetes cluster — node pools, the Kubernetes API, custom operators, network plugins, service mesh options, persistent volume support. You are responsible for Kubernetes version upgrades, node pool configuration, and cluster-level concerns.

Use AKS when:

• Your organisation already runs Kubernetes and has the expertise to operate it
• You need features Container Apps does not expose: custom CRDs, cluster-level networking policies, stateful workloads with persistent volumes, Istio service mesh
• You are migrating an existing Kubernetes deployment from another cloud
• Compliance requirements mandate that you manage your own Kubernetes cluster configuration

AKS has a steeper learning curve and more operational surface area than Container Apps. For teams new to containers, starting with Container Apps and graduating to AKS only if its specific features are needed is a common and sensible progression.

A decision pattern for choosing

Start at the top and stop at the first description that matches your workload:

1. Is it a one-off job or batch task that runs and exits? → Azure Container Instances
2. Is it a single-container web app or API where the team knows App Service? → App Service (container)
3. Does it need to scale to zero, have multiple services communicating, or benefit from event-driven scaling? → Azure Container Apps
4. Does it need full Kubernetes features or does the team already run Kubernetes? → AKS
5. Does it need OS-level customisation, custom kernel modules, or non-containerisable dependencies? → VM or VM Scale Sets

Most new containerised applications land on Container Apps. Most existing Kubernetes workloads from other clouds land on AKS. Most web APIs from teams with existing App Service experience land on App Service.

Building and storing container images

All five services pull container images from a registry. Azure Container Registry (ACR) is Azure’s private container registry — the equivalent of Docker Hub but private and integrated with Azure RBAC, managed identities, and the Azure portal.

Build and push a container image to ACR:

# Create an Azure Container Registry
az acr create \
  --resource-group my-rg \
  --name myorgacr \
  --sku Basic

# Log in to the registry
az acr login --name myorgacr

# Build and push using the ACR build service (no local Docker needed)
az acr build \
  --registry myorgacr \
  --image myapp:latest \
  .

See Azure Container Registry overview for access control, vulnerability scanning, and image lifecycle management.