Containers: ACI, Container Apps and AKS

Three levels of container control

Azure Container Instances (ACI) runs a container or small group on demand, billed per second: good for jobs and quick tasks, no orchestration. Azure Container Apps is a serverless container platform built on Kubernetes, KEDA and Envoy, but it hides the cluster: you get HTTPS ingress, revisions with traffic splitting, Dapr integration and event-driven autoscaling, including scale to zero. Azure Kubernetes Service (AKS) is managed Kubernetes: Azure runs the control plane, you run node pools and get the full Kubernetes API, Helm charts and operators, along with the responsibility for upgrades and cluster design. All three pull images from a registry, typically Azure Container Registry (ACR), ideally using a managed identity with the AcrPull role rather than admin credentials.

A container app that scales on HTTP load

One command creates the environment and the app from an image.

az acr create -g rg-shop-dev-cin -n acrshopdev --sku Basic
az acr build -r acrshopdev -t shop-api:1.0 .

az containerapp up -g rg-shop-dev-cin -n ca-shop-api \
  --image acrshopdev.azurecr.io/shop-api:1.0 \
  --ingress external --target-port 8080

az containerapp update -g rg-shop-dev-cin -n ca-shop-api \
  --min-replicas 0 --max-replicas 10 \
  --scale-rule-name http-rule --scale-rule-type http \
  --scale-rule-http-concurrency 50

Do not reach for AKS by default

AKS is powerful but you inherit Kubernetes upgrades, networking choices and security hardening. If your team needs only HTTP services and background workers, Container Apps or App Service usually ships faster with less operations work.

Quick check: A team wants containers with HTTPS ingress, revisions and scale-to-zero, without managing Kubernetes. Which service fits?

• Azure Kubernetes Service
• Virtual Machine Scale Sets
• Azure Container Apps
• Azure Container Registry