Container Instances
Azure Container Instances runs a single container, or a small group of them, in seconds — with no orchestrator, no cluster, and no node fleet to manage. You hand it an image and resource limits; it starts the container, runs it, and bills per second while it runs. It is the simplest way to put a container in the cloud.
ACI is built for short-lived and bursty work: a build agent, a scheduled data job, an event-triggered task launched from a Function or Logic App. It is deliberately not an orchestrator — the moment a workload needs autoscaling, health-based replacement, or rolling deployments, it has outgrown ACI and belongs on Container Apps or AKS.
Container Groups
The unit of deployment is a container group — one or more containers that share a lifecycle, a network namespace, and storage, scheduled together on the same host. Containers in a group reach each other over localhost and can share a mounted volume, which makes the group the right shape for a main container plus a logging or proxy sidecar.
A single-container group is the common case. Multi-container groups exist for the sidecar pattern, not as a way to run a whole application — there is no service discovery or load balancing between groups.
Use Cases
ACI shines when the alternative is standing up a cluster for a task that runs for minutes. Burst compute that exceeds a cluster's capacity, CI build agents that appear and vanish, and event-driven one-off jobs are the canonical fits. Functions and Logic Apps frequently launch ACI groups for work that exceeds a function's execution limits but does not justify a cluster.
Networking and Storage
A container group gets a public IP and DNS name by default, or it can be injected into a VNet subnet for private access to other resources. Persistent data mounts from Azure Files, since the container's own filesystem is ephemeral and gone when the group stops.
Limits
ACI has no built-in autoscaling, no orchestration, and no health-based rescheduling across hosts. A restart policy — Always, OnFailure, or Never — governs what happens when the container exits, and OnFailure with Never-style run-to-completion is the model for batch jobs. For anything that needs to scale on demand or self-heal, the correct answer is Container Apps.
Container Instances — A single container or group, started fast, no orchestration. Choose it for burst jobs, build agents, and one-off tasks.
Container Apps — Serverless containers with autoscaling, revisions, and scale-to-zero. Choose it when the workload is a service or needs to scale.
AKS — Full Kubernetes. Choose it only when you need the Kubernetes API, operators, and node-level control.
- Running a scaling web service on ACI — it has no autoscaling or load balancing, so it cannot grow with traffic; that is Container Apps' job.
- Expecting health-based rescheduling — ACI will not move a failed container to a healthy host the way an orchestrator does.
- Shipping a multi-hundred-megabyte image — start time is dominated by the pull, and a large image makes the per-second model slow and costly.
- Leaving a job container with an Always restart policy so it restarts forever instead of completing once and stopping.
- Writing important data to the container filesystem, which is ephemeral — it vanishes when the group stops unless an Azure Files volume is mounted.
- Putting a group on a public IP when it only ever talks to private resources, instead of injecting it into a VNet.
- Use ACI for short-lived, bursty, or scheduled tasks; reach for Container Apps the moment the workload needs to scale or self-heal.
- Keep images small with multi-stage builds so per-second billing is not dominated by image pull time.
- Set the restart policy to OnFailure or Never for run-to-completion jobs so they stop when done.
- Mount Azure Files for any data that must outlive the container group.
- Inject the group into a VNet when it accesses private resources, rather than exposing a public IP.
- Launch ACI from Functions or Logic Apps for event-driven jobs that exceed a function's execution limits.
Knowledge Check
Why is ACI the wrong choice for a public web service that must scale with traffic?
- ACI has no built-in autoscaling or load balancing — it runs containers but does not orchestrate them
- ACI cannot pull images from a private registry
- ACI containers cannot listen on HTTP ports
- ACI bills a fixed flat monthly fee per container that makes scaling out uneconomical at higher traffic
What is a container group in ACI?
- One or more containers sharing a lifecycle, network, and storage on the same host
- A Kubernetes namespace managed by ACI
- A set of identical container replicas placed behind a managed load balancer for scaling
- An autoscaling policy applied to a single running container
A batch job container keeps restarting after it finishes successfully. What is the likely cause?
- The restart policy is Always instead of OnFailure or Never
- The image is too large to cache
- The group has no public IP
- The container group is not injected into a private VNet subnet
You got correct