Azure Container Instances: Run a Container in Seconds, Without Running a Single Server
An intermediate guide to Azure Container Instances. Learn how container groups, images, resources, networking, storage, identity, and restart policies work, when to choose this service, and how to build secure, affordable, and reliable container workloads without managing any virtual machines.
Imagine you need a taxi. You do not want to buy a car, hire a mechanic, find parking, and pay insurance just to make one trip across town. You open an app, a car arrives within minutes, takes you where you need to go, and the meter runs only while you ride. When the trip ends, the car leaves and you pay nothing more. Azure Container Instances is that taxi service for software. You hand Azure a packaged application, called a container, and Azure starts it within seconds on its own infrastructure. You pay only for the seconds it runs, and you never see or manage the machine underneath.
1What Is Azure Container Instances?
Start with a plain definition, then add the details one layer at a time.
Azure Container Instances, often shortened to ACI, is an Azure service that lets you run containers directly in the cloud without creating or managing virtual machines and without setting up an orchestration system such as Kubernetes. You give ACI a container image, tell it how much processing power and memory the container needs, and it runs the container for you.
A container is a lightweight package that holds an application together with everything it needs to run: the code, the runtime, the libraries, and the settings. Because the package carries its own environment, it runs the same way on a developer’s laptop and in the cloud. ACI is described as serverless for containers, because from your point of view there are no servers to size, patch, or maintain. Azure finds capacity, starts your container, and bills you by the second.
ACI is intentionally simple. It does one job well: start containers quickly and stop charging when they finish. It does not try to be a full platform with automatic scaling, built-in load balancing, or service discovery. Those features belong to other Azure services, and knowing where ACI ends and others begin is one of the most useful skills for choosing the right tool.
If virtual machines are like buying a car, and Kubernetes is like running an entire taxi company with dispatchers and garages, then ACI is like hailing a single taxi through an app. It is quick and simple, perfect for one trip, but you would not use it to run a whole city’s transport network.
2The Problem ACI Solves
A tool makes sense when you know the pain it removes.
Containers are wonderful, but running them has traditionally needed infrastructure. To run even one container in production you needed a machine with a container engine installed, an operating system to patch, networking to configure, and monitoring to set up. For a short job that runs for ten minutes a day, that machine would sit idle for the remaining hours and still cost money.
Servers for tiny jobs
Creating and maintaining a virtual machine just to run one short container wastes time and money.
Idle capacity
Machines billed by the hour keep charging even when the container work has finished.
Complexity of orchestrators
Systems like Kubernetes are powerful but heavy. Using one for a simple task is like using a crane to lift a book.
Slow experiments
Developers want to try an image quickly, run a test, or process a file without a long setup.
Unpredictable bursts
Sudden bursts of work, such as processing a large batch, need many containers briefly, and then nothing.
Patching and security chores
Every machine you own needs updates, hardening, and monitoring, adding work unrelated to the application.
ACI answers these with fast startup, per-second billing, and no infrastructure to manage. You start containers when you need them and delete them when you do not.
3Container Basics You Must Know First
A few container words explain almost everything that follows.
Container
A running, isolated instance of an application and its environment. It shares the host’s kernel but has its own file system and processes.
Image
A read-only template used to create containers. It is like a frozen snapshot of an application and everything it needs.
Registry
A storage place for images, such as Azure Container Registry or Docker Hub, from which services pull images to run them.
Tag
A label attached to an image version, such as a version number, that tells you which version you are running.
Entry point and command
The program that starts when the container starts, and the arguments passed to it.
Environment variable
A named setting handed to the container at startup, used to configure it without changing the image.
Volume
A storage area that a container can read from and write to, which can outlive or be shared beyond the container’s own file system.
Port
A numbered doorway on a container through which network traffic enters or leaves.
flowchart LR
DEV["Developer builds an image"] --> REG["Registry stores the image"]
REG -->|Pull| HOST["Host runs the image"]
HOST --> C1["Container instance 1"]
HOST --> C2["Container instance 2"]
An image is a recipe card together with all measured ingredients sealed in a box. A container is a dish cooked from that box. You can cook as many identical dishes as you like from the same box design, and each dish is separate from the others.
Containers are not virtual machines. They start faster and are smaller because they share the host’s operating system kernel instead of carrying a whole operating system each. ACI adds extra isolation around containers, which is covered in the security chapter.
4Core Concepts: Container Groups and Containers
The most important idea in ACI is the container group. Learn it well.
In ACI, the unit you create and manage is not a single container but a container group. A container group is a collection of one or more containers that are scheduled on the same host machine and share a lifecycle, a network, and optionally storage volumes. If you know Kubernetes, a container group is very similar to a pod.
All containers in a group start together, run on the same machine, and stop together. They share one IP address and one port space, so they can talk to each other through localhost. This design makes it easy to run a main application along with helper containers, such as a logging agent or a proxy, as a single unit.
Container group
The top-level ACI resource. It holds containers, the shared network settings, volumes, restart policy, and identity.
Container
A single image-based process inside the group, with its own CPU and memory request and its own command and variables.
Init container
A container that runs and completes before the main containers start, used for setup tasks such as preparing files.
Sidecar container
A helper container that runs alongside the main one, for tasks such as shipping logs or acting as a local proxy.
Shared network
All containers in the group share one IP address and can reach each other on localhost.
Shared volumes
Storage that can be mounted into several containers of the group, letting them exchange files.
flowchart TD
CG["Container Group: one host, one lifecycle"]
CG --> IC["Init container: prepares data first"]
CG --> MAIN["Main container: your application"]
CG --> SIDE["Sidecar container: log shipper or proxy"]
CG --> NET["Shared IP address and port space"]
CG --> VOL["Shared volume: files exchanged between containers"]
MAIN --- SIDE
MAIN --- VOL
SIDE --- VOL
IC --- VOL
A container group is a small apartment shared by flatmates. They live under one roof, share the same street address and the same fridge, move in and out together, and can talk to each other simply by walking into the next room.
Putting unrelated applications into one group to save a little money. Because the group scales and restarts as one unit and shares one network, unrelated applications can interfere with each other. Put tightly connected containers together, and separate everything else.
5Inside the Service: How ACI Starts a Container
Knowing the startup steps explains why some containers start quickly and others take longer.
When you create a container group, ACI performs several steps behind the scenes. Most of the waiting time normally comes from one step: pulling the image from the registry. A small image on a nearby, fast registry starts in a few seconds. A huge image or a slow registry can take much longer.
You submit the container group request
The request names the images, resource sizes, ports, variables, volumes, and restart policy, either through the portal, the command line, a template, or an automation tool.
Azure validates and places the group
ACI checks your quota and settings, and chooses a host with enough capacity in the region.
The host prepares network and storage
An address is assigned, any virtual network connection is set up, and volumes are attached.
Images are pulled
The host authenticates to the registry and downloads the image layers. Cached layers on the host are reused when available.
Init containers run, then main containers start
Setup tasks finish first, and then the containers that make up your application begin running.
Billing starts and the workload runs
Billing is based on the time the group’s resources are allocated, counted per second, until it stops or is deleted.
sequenceDiagram
participant U as You or your automation
participant ACI as ACI Service
participant H as Host in the region
participant R as Container Registry
U->>ACI: Create container group
ACI->>ACI: Check quota and settings
ACI->>H: Place the group on a host
H->>R: Pull the image layers
R-->>H: Image
H->>H: Run init containers, then main containers
H-->>ACI: Group is running
ACI-->>U: Status running, with IP address if requested
Keep images small
Smaller images download faster. Use lean base images and remove unneeded files.
Use a registry in the same region
Azure Container Registry in the same region as the container group reduces pull time and avoids data transfer cost.
Order layers wisely
Put rarely changing layers first so more layers can be reused from cache.
Avoid heavy startup work
Do large downloads and setup in the image build, not at container start.
Starting a container is like a taxi arriving after you book. The driving time is quick, but the longest wait is often your luggage: a small bag is loaded in seconds, while a heap of heavy suitcases, a big image, takes much longer.
6Resources and Sizing: CPU and Memory
You choose the size of each container, and the group’s total decides the price.
For each container you specify a request for virtual CPU cores and memory in gigabytes. These requests tell ACI how much capacity to reserve. You can also set limits that cap how much a container may use. The sum of the containers’ requests becomes the resource size of the whole group, and that is what you are billed for.
CPU request
The number of virtual cores reserved for the container. Fractions are allowed, so small containers can be inexpensive.
Memory request
The amount of memory in gigabytes reserved for the container.
Limits
Optional maximums for CPU and memory a container may consume above its request, if the group has spare capacity.
GPU resources
Some regions and sizes have offered containers with graphics processors for machine learning and similar work. Availability, models, and support have changed over time, so check current documentation before planning around GPUs.
Maximum group size
There is an upper limit on cores and memory per group, and the limits differ by region, operating system, and over time. Check the current quotas.
Regional quotas
Each subscription has quotas for cores and groups per region, which you can request to increase when needed.
Measure the container locally
Run it on your machine and observe typical CPU and memory use under realistic work.
Start with modest requests
Choose a small size with some headroom, rather than a large size “to be safe”.
Watch metrics during test runs
Check CPU and memory metrics in Azure Monitor to see whether the container is starved or mostly idle.
Adjust and re-create
Resource sizes are generally changed by creating a new container group with new values, so tune them before relying on the job at scale.
A container that tries to use more memory than it is allowed is stopped by the system, often with an out-of-memory error. If a job fails mysteriously after running for a while, check memory use first, and increase the memory request if needed.
Choosing CPU and memory is like choosing the size of a hired van. Too small and your boxes will not fit, so the trip fails. Too large and you pay for empty space on every kilometer.
7Linux and Windows Containers
ACI can run both kinds, but they are not equal in features.
Container groups run either Linux containers or Windows containers, and one group cannot mix the two. Linux is the most capable and most commonly used option on ACI. Windows containers are supported, but with some limitations, such as fewer features for networking, multi-container groups, and volumes. Windows images can also be large, which increases startup time, and Windows usage has a higher price.
| Point | Linux containers | Windows containers |
|---|---|---|
| Feature coverage | Broadest, including multi-container groups and most volume types | More limited, so check support for each feature you need |
| Image size | Often small, so faster startup | Often large, so slower startup |
| Price | Lower | Higher, because of license costs |
| Typical use | New cloud-native apps, scripts, batch jobs, tools | Existing Windows-based applications and tools |
| Mixing in one group | Not allowed with Windows | Not allowed with Linux |
If you have a choice, build for Linux. It starts faster, costs less, and supports more of ACI’s features. Use Windows containers only when an application truly needs them, and verify the specific features you depend on.
Linux containers are like compact cars: quick to start, cheap to run, and welcome nearly everywhere. Windows containers are like large trucks: needed for some loads, but slower to get going, more costly, and not allowed in every lane.
8Restart Policies: What Happens When a Container Stops
The restart policy decides whether a finished container comes back, and it changes the character of the whole workload.
Always
The container is restarted whenever it stops, whether it exited with success or failure. Use it for long-running services such as a small API or a worker waiting for messages. The group keeps running, and billing continues.
OnFailure
The container is restarted only if it exits with an error. If it finishes successfully, the group stops. Use it for jobs that should be retried after failure but not repeated after success.
Never
The container is never restarted. It runs once, and when it finishes, the group moves to a terminated state and compute billing stops. Use it for one-time tasks, batch jobs, and scripts.
| Policy | After success | After failure | Best for |
|---|---|---|---|
| Always | Restart | Restart | Long-running services and workers |
| OnFailure | Stop | Restart | Jobs that must succeed, with retries |
| Never | Stop | Stop | One-time tasks, tests, and scripts |
flowchart TD
RUN["Container finishes"] --> EX{"Exit result?"}
EX -->|Success| P1{"Restart policy?"}
EX -->|Failure| P2{"Restart policy?"}
P1 -->|Always| R1["Restart"]
P1 -->|OnFailure or Never| S1["Group terminates, compute billing stops"]
P2 -->|Always or OnFailure| R2["Restart"]
P2 -->|Never| S2["Group terminates with failure state"]
Problem
Leaving the default restart policy on a one-time batch job, so the job restarts again and again after it has already finished its work.
Why It’s Harmful
The job may repeat, duplicating data or sending messages many times, and billing continues for a group that was supposed to stop. A restart loop can run unnoticed for days.
Correct Approach
Choose Never or OnFailure for jobs, design the job to be safe to repeat, and set alerts or deletion steps so finished groups do not linger.
The restart policy is the instruction you give a delivery driver. “Always return and deliver again” suits a bus route. “Come back only if the parcel was not delivered” suits a one-off parcel. “Go once and stop” suits a single special errand.
9The Container Group Life Cycle
A group moves through states, and each state has billing and behavior consequences.
Pending or creating
Azure is placing the group and preparing resources. Image pulls happen here.
Running
At least one container is running, and the group’s resources are allocated and billed.
Succeeded or terminated
All containers have completed and will not restart. The group object still exists, but compute is no longer running.
Failed
A container exited with an error and the policy did not restart it, or the group could not be created.
Stopped
You can stop a group, which ends its containers. Restarting it starts the containers again, possibly on a different host with a different address.
Deleted
The group and its resources are removed completely. Logs held by the service are lost unless you sent them elsewhere.
flowchart LR
CR["Create"] --> PEND["Pending: pulling images"]
PEND --> RUN["Running"]
RUN --> DONE["Succeeded or terminated"]
RUN --> FAIL["Failed"]
RUN --> STOP["Stopped by you"]
STOP --> RUN
DONE --> DEL["Deleted"]
FAIL --> DEL
STOP --> DEL
Container logs that are held only by ACI are lost when the group is deleted. For any job that matters, send logs to a durable place such as a Log Analytics workspace or a storage account before the group goes away.
A container group is like a hired taxi. It is booked, it arrives, it drives, and it finishes the trip. After the trip ends, it is no longer on the clock, but the booking record still exists until you delete it, and the dashcam footage may be erased with it.
10Networking: Public Addresses and Virtual Networks
By default, a container group is reachable from the internet if you ask for it. You can also place it inside your private network.
Public IP and DNS name label
You can give a container group a public IP address and open chosen ports. You can also assign a DNS name label, which gives the group a readable address such as a name in a regional Azure domain. The public address is not permanent: if you delete and recreate the group, you usually get a new address, so rely on names, not addresses, and remember that restarts may change the address.
Virtual network deployment
You can deploy a container group into a subnet of your virtual network. The subnet must be delegated to ACI, meaning it is reserved for container groups. The group then receives a private address from the subnet and can talk to other private resources, such as databases on private endpoints, without crossing the public internet. In this mode, the group typically has no public address and is not reachable from the internet directly.
| Option | Address | Reachable from internet | Reach private resources | Typical use |
|---|---|---|---|---|
| Public IP | Public, may change on recreate | Yes, on ports you open | Only through public endpoints of those services | Quick tests and simple public tools |
| Virtual network subnet | Private from the delegated subnet | No, unless fronted by another service | Yes, through the network | Internal jobs and private back ends |
| Fronted by a gateway or load balancer | Gateway has the public address | Through the gateway, with security rules | Yes, through the network | Production-style access with firewall and TLS |
flowchart LR
USER["Users on the internet"] --> AG["Application Gateway with firewall and HTTPS"]
AG --> SUBNET
subgraph VNET["Your Virtual Network"]
subgraph SUBNET["Delegated subnet for container groups"]
CG["Container group with private IP"]
end
PE["Private endpoint: Database"]
PEKV["Private endpoint: Key Vault"]
end
CG --> PE
CG --> PEKV
Delegated subnet rules
The subnet is reserved for container groups of this service, so you cannot mix other resource types in it. Plan its size, because each group consumes addresses.
Network security groups
You can apply security group rules to the delegated subnet to control inbound and outbound traffic.
Outbound address
Outbound traffic from a subnet-deployed group can be given a stable public address through a NAT gateway on the subnet, helpful when partners allow only known addresses.
Features differ by mode
Some features, such as certain DNS options, apply only to public or only to virtual network groups. Check current compatibility before choosing.
ACI does not terminate secure web connections for you, and it does not distribute traffic across several groups. If you need HTTPS, certificates, firewalling, or load balancing, place Application Gateway, Front Door, or another service in front, or build the secure connection into your container.
A public IP is a taxi parked on the street with a phone number on its door, open to anyone who calls. A virtual network deployment is a taxi parked inside a gated company yard, reachable only by staff, with a reception desk if outsiders need to be let in.
11Storage and Volumes
A container’s own file system is temporary. Volumes are how you keep or share data.
The writable layer of a container disappears when the container group is deleted or recreated. For anything you need to keep, or share between containers, you mount a volume. ACI supports several volume types.
Azure Files share
A persistent network file share that survives container groups. Several groups can mount it, which makes it useful for shared inputs and durable outputs.
Empty directory
A temporary, initially empty folder shared by containers in the group, which exists as long as the group does. Good for scratch space and passing files between init, main, and sidecar containers.
Secret volume
Delivers secret values as files inside the container, so sensitive values do not appear in environment variables or images.
Git repository volume
Clones a repository into a folder at startup, useful for pulling scripts or configuration.
| Need | Volume choice | Why |
|---|---|---|
| Keep job output after the group is deleted | Azure Files share | Data lives outside the group |
| Share temporary files between containers in the group | Empty directory | Simple and fast, disappears with the group |
| Provide a certificate or key file | Secret volume | Keeps secrets out of images and variables |
| Fetch scripts at startup | Git repository volume | Easy delivery of small, versioned files |
Decide whether the data must survive
If losing it is acceptable, a temporary volume is enough. If not, use external storage.
Create the storage and give access
For a file share, create a storage account and share, and provide credentials or identity-based access.
Mount the volume at a path
In each container that needs it, mount the volume at a chosen folder.
Write results to the mounted path
Have your program write outputs there, so they remain after the container finishes.
Volume support differs between Linux and Windows containers, and a mounted file share is a network drive, so it is slower than local disk for many small operations. For data-heavy jobs, consider reading and writing through storage services directly from your code.
The container’s own disk is a notepad on the taxi seat that is thrown away at the end of the trip. A file share is a locker at the central station, where you can leave things that stay available after the taxi is gone.
12Configuration: Environment Variables and Secrets
One image, many behaviors: configuration is how you change what a container does without rebuilding it.
Containers read settings from environment variables, command arguments, and files. ACI lets you set normal environment variables, which are visible in the group’s configuration, and secure environment variables, whose values are hidden from the portal and command output after creation. Secure variables are better than plain ones for sensitive values, but they are still values that your deployment process had to know, so better options exist.
Plain environment variables
Fine for non-sensitive settings such as modes, endpoints, and feature switches.
Secure environment variables
Hidden from display after creation. Use only when other options are unavailable.
Secret volumes
Mount secrets as files, avoiding the environment variable exposure paths.
Managed identity and Key Vault
The container uses its identity to fetch secrets at run time, so the deployment never handles the secret at all.
Command and arguments
Override the image’s default command to run different tasks from the same image.
Problem
Baking passwords and keys into the container image, or passing them as plain environment variables in templates stored in source control.
Why It’s Harmful
Images are copied, shared, and stored in registries, and anyone who can pull the image or read the template sees the secret. Secrets in images live forever in layer history.
Correct Approach
Keep images free of secrets, use managed identities to read from Key Vault at run time, and use secret volumes or secure variables only when necessary.
Environment variables are notes handed to the taxi driver at pickup: the destination and the preferred route. A secret should not be a note that anyone can read over the driver’s shoulder. It is better for the driver to carry a staff badge that opens the vault when needed.
13Identity: Managed Identities and Registry Access
Containers should prove who they are to Azure without carrying passwords.
A container group can have a managed identity, which Azure creates and manages. With it, the code inside the containers can request tokens from Azure and use them to reach services such as Key Vault, Storage, and databases that support identity-based access, once roles are assigned. There are system-assigned identities tied to one group, and user-assigned identities that can be shared and that survive deletion of the group.
The same idea applies to pulling images. Instead of storing registry usernames and passwords in the container group, you can let the group’s managed identity pull from Azure Container Registry, after giving the identity the right to pull. This removes a stored credential from your deployments.
Create a user-assigned managed identity
It exists independently, so you can grant it access before creating any container group.
Assign roles on the target resources
Give permission to pull images from the registry, read secrets from Key Vault, or write to storage, using the narrowest roles.
Attach the identity to the container group
Specify the identity at creation time, and configure the registry pull to use it.
Code requests tokens at run time
The application uses the identity endpoint to obtain tokens and calls Azure services without any stored secrets.
sequenceDiagram
participant CG as Container Group with managed identity
participant AAD as Microsoft Entra ID
participant ACR as Container Registry
participant KV as Key Vault
CG->>AAD: Get token for the registry
AAD-->>CG: Token
CG->>ACR: Pull image with token
ACR-->>CG: Image
CG->>AAD: Get token for Key Vault
AAD-->>CG: Token
CG->>KV: Read secret with token
KV-->>CG: Secret value
Prefer user-assigned identities for container groups that are created and deleted frequently. The identity and its role assignments stay in place, so each new group works immediately without waiting for new permissions to spread.
A managed identity is a staff badge issued to the taxi company. The driver shows the badge at the depot to collect the vehicle, and at the warehouse to collect goods, without carrying any keys or cash that could be lost.
14Security: Isolation and Layers of Protection
Running other people’s code safely requires strong isolation, and your own choices add more layers.
ACI is designed so that container groups from different customers are isolated from one another. Each container group runs in its own isolated environment, using virtualization-based isolation, so that a problem inside one group cannot reach another customer’s group on the same hardware. This is a stronger boundary than containers sharing a kernel on an ordinary machine. Your own settings then add further protection.
Platform isolation
Hypervisor-level isolation between container groups, managed by Microsoft.
Image supply chain
Use trusted base images, pull from your own registry, scan images for vulnerabilities, and pin versions by digest or specific tags.
Identity and secrets
Use managed identities, Key Vault, and secret volumes. Avoid secrets in images and plain variables.
Network controls
Deploy into a virtual network, use network security groups, avoid public addresses where possible, and front public services with a gateway and firewall.
Least privilege inside the container
Run the process as a non-administrator user where possible, and give the identity only the roles it needs.
Management access control
Use role-based access control to decide who can create, change, delete, and read logs of container groups.
Confidential options
Some regions offer confidential container groups that add hardware-based protection of data in use. Availability and features change, so check the current offering if you need it.
Build from minimal, trusted base images
Fewer packages mean fewer vulnerabilities and smaller images.
Scan and sign images
Scan for known vulnerabilities in the registry or build pipeline, and only deploy images that pass.
Pull privately with identity
Use a private registry and a managed identity, rather than public images and stored passwords.
Keep workloads off the public internet
Use a virtual network and private connections to data services, and expose only what must be public, behind a gateway.
Log and review
Send container logs and activity logs to a central workspace, and review role assignments regularly.
Running an unvetted public image from a registry you do not control, with a public address and powerful permissions. A malicious or vulnerable image becomes a doorway into your environment. Treat images like software you install on a server.
Platform isolation is the strong wall between apartments in the building. But you still decide whom you let in, what you leave on the doorstep, and which keys you hand out. A strong wall does not help if you give your spare key to a stranger.
15Pricing and Cost Control
ACI bills by the second, so short jobs are cheap and forgotten services are expensive.
Billing is based on the resources allocated to the container group: the number of virtual CPU cores and the amount of memory, multiplied by the time the group is running, counted in seconds. GPU resources and Windows software have their own, higher rates. Other costs include any public IP addresses, data transfer out of Azure, registry storage and pulls, file share storage, logging, and networking components such as gateways. Prices vary by region and change over time, so use the official pricing page and the calculator.
vCPU seconds
Cores allocated times seconds running.
Memory seconds
Gigabytes allocated times seconds running.
Operating system and special hardware
Windows, GPUs, and confidential options add to the rate.
Surrounding services
Registry, storage, networking, logs, and data transfer are billed separately.
| Workload shape | ACI cost behavior | Comment |
|---|---|---|
| A ten-minute job once a day | Very low, you pay for ten minutes of resources | An ideal fit compared with an always-on server |
| A burst of one hundred short jobs | Pay for the total seconds used by all groups | Quota and startup time become the main limits |
| A small service running all day, every day | Continuous billing for the full period | Often more expensive than platforms with reserved or shared capacity |
| Forgotten test group left running | Billing continues until stopped or deleted | A common source of waste, so clean up |
Right-size each container
Request only the CPU and memory that testing shows you need.
Use Never or OnFailure for jobs
Make sure finished jobs stop billing, and delete groups when their results are saved.
Shorten startup and run time
Small images, nearby registries, and efficient code reduce billed seconds.
Compare with alternatives for always-on work
For services that run continuously, compare ACI with Container Apps, App Service, or virtual machines with commitments.
Tag and monitor
Tag groups with owner and purpose, review cost analysis, and set budgets and alerts.
Rates for CPU, memory, GPUs, Windows, and any spot or discount options change over time, and regions differ. Always confirm current prices before sizing a large or long-running workload.
Paying by the second is like a taxi meter. A short trip costs little. But if you leave the taxi waiting outside your house with the meter running for the whole weekend, the bill is far more than hiring a car for the weekend would have been.
16Monitoring, Logs, and Troubleshooting
Containers that run briefly and disappear need their evidence saved on purpose.
Container logs
The output a container writes to its standard output and error streams, viewable in the portal or command line while the group exists.
Events
A record of lifecycle steps such as pulling images, starting, and failing, with messages that explain startup problems.
Metrics
CPU, memory, and network measurements in Azure Monitor, for the group and per container.
Log Analytics integration
Send container logs and events to a workspace, so they survive deletion and can be queried and alerted on.
Exec into a running container
Open a shell inside a running container to inspect files and processes, helpful for debugging, though not meant as a routine tool.
Activity log
Records who created, changed, or deleted container groups.
| Symptom | Likely cause | What to check |
|---|---|---|
| Group stuck in pending | Slow or failing image pull, or no capacity | Events for pull errors, image size, registry access, and regional quota |
| Image pull fails | Wrong image name, missing credentials, or no network path to the registry | Image name and tag, identity roles, registry firewall |
| Container exits immediately | The command finishes at once, or crashes at startup | Logs, command and arguments, and whether the process stays in the foreground |
| Container restarts repeatedly | Crash loop with the Always policy | Logs, exit code, memory use, and dependencies |
| Out-of-memory termination | Memory request too small | Memory metrics and the job’s real needs |
| Cannot reach the container | Port not exposed, firewall rules, or wrong address | Open ports, network security rules, and current IP or name |
| Cannot reach a database | Network path or firewall blocks the container’s outbound address | Virtual network settings, private endpoints, and allowed addresses |
Send logs to a workspace from the start
Configure Log Analytics at creation so evidence survives deletion.
Write clear logs from the application
Include start, progress, and finish messages, and write errors to standard error.
Alert on failures
Alert when groups fail, restart too often, or run longer than expected.
Check events first for startup problems
Many early failures are explained by events before the application even runs.
A short-lived container is like a taxi that leaves after dropping you off. If you did not record the trip details, such as the route and any problems, nobody can reconstruct what happened later. Saving the logs is writing the trip report before the taxi disappears.
17Reliability and Availability
ACI is simple, so reliability is something you design around it, not something it gives automatically.
A single container group is a single instance. If the host has a problem, the group may be restarted elsewhere, but there is no built-in clustering, load balancing, or automatic replication across groups. In some regions you can request that a group be placed in a specific availability zone, which protects against zone failure only if you run groups in several zones yourself.
Make work idempotent
Design jobs so that running them twice gives the same result, because retries and restarts will happen.
Use queues for work
Let containers pull tasks from a queue, so a failed container simply leaves the task for another to pick up.
Run several groups for availability
For a service, create several groups in different zones behind a load balancing service, and manage their count yourself.
Keep state outside
Store results and progress in storage, databases, or queues, not inside the container.
Plan for startup failure
Capacity or image pull problems can delay or prevent a start. Add retries and alerts in the system that launches containers.
flowchart LR
PROD["Producer adds tasks"] --> Q["Message queue"]
Q --> C1["Container group 1"]
Q --> C2["Container group 2"]
Q --> C3["Container group 3"]
C1 --> OUT["Results in storage or database"]
C2 --> OUT
C3 --> OUT
C2 -. fails .-> Q
Running a customer-facing service in one container group and expecting it to be highly available. One group is one point of failure, with no automatic scaling and no built-in traffic distribution. For critical always-on services, choose a platform that provides these features.
One taxi is one driver. If that driver falls ill, the trip fails. A taxi company with a dispatch queue can send another driver. Reliability with ACI means building the dispatch system yourself, using queues and several groups.
18Launching Container Groups: Portal, Command Line, Templates, and Code
There are many ways to start a container group, and automation is where ACI shines.
| Method | What it is | Best for |
|---|---|---|
| Azure portal | A web form where you pick the image, size, ports, and options | Learning and one-off tests |
| Azure CLI and PowerShell | Commands you can run from a terminal or script | Quick tasks and simple automation |
| Infrastructure templates such as Bicep, ARM, and Terraform | A text description of the container group stored in version control | Repeatable, reviewed deployments |
| Declarative group definition files | A file that describes a multi-container group, then deployed with tools | Multi-container groups with volumes and sidecars |
| SDKs and APIs | Code that creates groups programmatically | Applications that launch containers on demand |
| Event and workflow tools | Logic Apps, Functions, Data Factory, and pipelines that start groups in response to events | Event-driven and scheduled jobs |
Build and push the image
A pipeline builds the image, scans it, and pushes it to your registry with a version tag.
Define the group as code
Describe the images, resources, restart policy, identity, network, and volumes in a template.
Launch on a trigger
A schedule, an event, a queue message, or a pipeline step creates the container group.
Watch and collect results
The launcher waits for completion, checks the state, collects outputs from storage, and reads logs.
Delete the group
When results are safe, the launcher deletes the group, so nothing lingers or costs money.
flowchart LR
TR["Trigger: schedule, event, or pipeline"] --> LA["Launcher: Logic App, Function, or pipeline step"]
LA -->|Create| CG["Container group runs the job"]
CG --> ST["Results saved to storage or database"]
CG --> LOG["Logs sent to Log Analytics"]
LA -->|Check state, then delete| CG
Because there is no built-in scheduler inside ACI, jobs that must run on a timetable are started by another service, such as a timer in Azure Functions, a Logic App recurrence, a Data Factory trigger, or a pipeline schedule.
Automation is a dispatch office that books a taxi for each job, checks that it arrived and finished, collects the delivery receipt, and cancels the booking afterwards. No human has to stand by the road waving at taxis.
19Design Patterns for ACI
A handful of patterns cover most good uses of the service.
Run-to-completion batch job
A container processes a file or a batch of records and exits. The restart policy is Never or OnFailure. Results go to storage, logs go to a workspace, and the group is deleted afterwards.
Queue-driven workers
Several container groups read tasks from a queue, process them, and exit or wait for more. A launcher starts more groups when the queue grows, and removes them when it empties.
Sidecar logging or proxy
A main container does the work, while a sidecar ships its logs or acts as a local proxy for network calls, sharing the group’s network and a volume.
Init container preparation
An init container downloads data or prepares a configuration file into a shared volume before the main container starts, keeping the main image simple.
Burst capacity for an orchestrator
A Kubernetes cluster uses virtual nodes backed by ACI to run extra pods during spikes, without adding virtual machines to the cluster. Features and support of this integration evolve, so check current guidance.
Ephemeral build and test agents
A continuous integration system starts a fresh container as an agent for each job, runs the build or tests, and discards it, ensuring a clean environment every time.
Temporary tools and diagnostics
Administrators start a container with debugging tools inside a virtual network to test connectivity or inspect a private service, then delete it.
flowchart TD
AKS["Kubernetes cluster at capacity"] -->|Overflow pods| VN["Virtual node"]
VN --> ACI1["ACI container group"]
VN --> ACI2["ACI container group"]
AKS --> NODES["Regular virtual machine nodes"]
These patterns are like different ways of using hired taxis: a single errand, a fleet fed by a dispatch board, a taxi with a helper in the back seat, or extra taxis hired only for the festival rush when your own cars are busy.
20What ACI Does Not Do: Limits to Plan Around
Knowing the boundaries prevents disappointment later.
No automatic scaling
ACI does not add or remove instances by itself. You or an external system create more groups.
No built-in load balancer or ingress
Traffic distribution, HTTPS termination, and path routing must come from another service.
No service discovery or orchestration
There are no rolling updates, health-based replacement across groups, or service names between groups.
Changes mean recreation
Many properties of a group, such as the image or resources, cannot be updated in place. You create a new group instead.
Size and quota limits
Groups have maximum sizes, and subscriptions have regional quotas, which differ by region and change over time.
No built-in scheduler
Timed runs must be triggered by another service.
Feature gaps for Windows and some modes
Windows containers and virtual network groups have fewer options in some areas.
Possible changing addresses
Public addresses and hosts can change when groups are recreated or restarted, so rely on names and gateways.
| If you need | ACI alone? | Add or choose |
|---|---|---|
| Automatic scale-out based on load | No | Container Apps or Kubernetes, or your own launcher logic |
| HTTPS with your own domain | No | Application Gateway, Front Door, or a reverse proxy sidecar |
| Rolling updates and revisions | No | Container Apps, App Service, or Kubernetes |
| Scheduled jobs | No, needs a trigger | Functions timer, Logic Apps, Data Factory, or Container Apps jobs |
| Simple one-off run to completion | Yes | Add storage and log destinations |
Problem
Building a full production microservices system out of dozens of container groups, with hand-made scripts for scaling, routing, and updates.
Why It’s Harmful
You end up reinventing an orchestrator, badly. Scripts become fragile, updates cause outages, and nobody understands the whole system.
Correct Approach
Use ACI for simple, short-lived, or bursty work, and choose a platform with built-in scaling, routing, and revision management for always-on microservices.
A taxi app is wonderful for individual trips. But you would not try to run a city’s entire bus network by booking one taxi at a time and writing the timetable by hand. For that, you need a proper transport authority with routes, schedules, and dispatch.
21ACI Compared with Other Azure Container Options
Several services run containers. Each fits a different job.
| Service | What it is | Management effort | Choose it when |
|---|---|---|---|
| Azure Container Instances | Single containers or groups started on demand, billed by the second | Lowest | Short jobs, bursts, simple tasks, tests, and tools |
| Azure Container Apps | Serverless containers with scaling, revisions, ingress, and jobs | Low | Microservices, APIs, and event-driven apps that need autoscaling and ingress |
| Azure App Service | Managed web hosting for code or containers | Low | Standard web apps and APIs with slots and built-in features |
| Azure Kubernetes Service | Managed Kubernetes clusters | High | Large, complex container platforms needing full orchestration control |
| Azure Batch | Managed large-scale parallel and batch compute | Medium | Very large batch and high-performance computing workloads |
| Virtual Machines with a container engine | Servers you manage yourself | Highest | Special operating system needs or full control |
| Azure Functions with containers | Event-driven functions packaged as containers | Low | Event-triggered code with a custom runtime |
flowchart TD
Q1{"How long does the container run?"}
Q1 -->|Seconds to hours, then finishes| ACI["Azure Container Instances"]
Q1 -->|Always on| Q2{"Need autoscale, revisions, and ingress?"}
Q2 -->|Yes, simple to operate| CA["Container Apps"]
Q2 -->|Standard web app, code or container| AS["App Service"]
Q2 -->|Full orchestration control| AKS["Kubernetes Service"]
Q1 -->|Massive parallel batch| BATCH["Azure Batch"]
If the container runs for a limited time and then finishes, think ACI. If it runs all the time and must scale, route, and update smoothly, think Container Apps, App Service, or Kubernetes.
22Real-World Use Cases
See how different organizations use Azure Container Instances.
A retailer processing nightly sales files
Each night, a workflow starts a container group that reads the day’s sales files from storage, cleans and aggregates them, writes the results to a database, and exits. The group is deleted afterwards, and the company pays for less than an hour of compute per day.
A software company running ephemeral build agents
The build system launches a fresh container for each build job, which provides a clean environment. When the job finishes, the container disappears, so there are no long-lived build servers to maintain.
A media company converting videos
When a video is uploaded, an event starts a container that converts it to several formats, using a mounted share for output. Many uploads at once simply start many groups, within quota.
A bank running scheduled reconciliation scripts
A scheduled workflow starts a container inside a private virtual network, where it reads from private databases through private endpoints, writes a report, and exits, leaving a full audit trail in the workspace.
A platform team bursting from Kubernetes
During promotional spikes, extra pods in a cluster are placed on virtual nodes backed by ACI, which avoids adding permanent virtual machine capacity for a few busy hours.
A data scientist trying a model quickly
A researcher runs a container with a prepared environment to test a model on a sample dataset, with results stored on a file share, and deletes the group when finished.
An operations team testing network connectivity
An administrator starts a container with network tools in a private subnet to check whether it can reach a database, then removes it, instead of building a virtual machine.
23Advantages and Trade-offs
An honest look helps you decide with open eyes.
Advantages
- Starts containers in seconds, with no virtual machines or clusters to manage
- Per-second billing, so short jobs are inexpensive
- Strong isolation between container groups from different customers
- Simple model, with multi-container groups for sidecars and init tasks
- Works with managed identities, Key Vault, virtual networks, and Azure Files
- Easy to automate from pipelines, workflows, functions, and code
- Useful as burst capacity for orchestrators
Disadvantages / Trade-offs
- No built-in autoscaling, load balancing, ingress, or rolling updates
- Always-on services can cost more than platforms built for them
- Many changes require recreating the group, and addresses may change
- Quotas and group size limits constrain very large workloads
- Windows containers and some modes have fewer features
- Logs and evidence disappear with the group unless saved elsewhere
- Reliability and scheduling must be designed around it
24Best Practices and Mistakes to Avoid
Habits that keep your container workloads fast, secure, reliable, and affordable.
Match the workload to the service
Use ACI for short, bursty, or simple container work. Choose another platform for always-on, auto-scaled services.
Keep images small, clean, and trusted
Use lean base images, scan them, store them in a private registry in the same region, and pin versions.
Choose the restart policy deliberately
Use Never or OnFailure for jobs, Always only for services, and design jobs to be safe to repeat.
Right-size CPU and memory
Measure first, start modest, and watch metrics, remembering that you pay for the allocated amount for every second.
Use identities, not stored passwords
Use managed identities for registry pulls and for access to Key Vault, storage, and databases.
Keep results and logs outside the group
Write outputs to storage or databases, and send logs to a workspace before the group is deleted.
Use private networking for sensitive work
Deploy into a delegated subnet, reach data through private endpoints, and put a gateway in front of anything that must be public.
Automate launch and cleanup
Use templates and workflows to create, monitor, and delete groups, so nothing lingers and costs nothing when idle.
Alert and tag
Alert on failed or long-running groups, tag with owner and purpose, and review cost regularly.
Problem
Leaving finished or test container groups in place “for later”, and never deleting them.
Why It’s Harmful
Groups with a restart policy of Always keep billing, and even stopped groups clutter the environment, hold quota, and confuse ownership. Costs and clutter grow quietly.
Correct Approach
Delete groups when results are saved, automate cleanup at the end of every job, and tag each group with an owner and expiry date.
Problem
Using the “latest” tag for images in production jobs, and pulling large images from a registry in another region on every run.
Correct Approach
Pin a specific version or digest, so every run uses the tested image, and keep the registry in the same region as the containers.
Why It’s Harmful
The word “latest” moves, so the same job can behave differently from day to day, and cross-region pulls make startup slow and add transfer cost.
Problem
Exposing a container group directly to the internet with a public address, open ports, no authentication, and no firewall.
Why It’s Harmful
Anyone can reach the application, scanners find it within hours, and any weakness in the image or code becomes an entry point to your environment.
Correct Approach
Prefer private deployment, add authentication, and place a gateway with a web application firewall and HTTPS in front of anything that must be public.
25Frequently Asked Questions
A container group is the ACI resource that holds one or more containers scheduled on the same host. They share a lifecycle, a network address, and optional volumes, and they start and stop together. A single container is just one process inside such a group. Even a single-container deployment is a group of one.
Compute billing continues while the group is running. If the restart policy is Never or OnFailure and the container finishes successfully, the group stops and compute charges stop, although storage, logs, and other related services still cost money. With the Always policy, the container restarts and billing continues until you stop or delete the group.
No. ACI does not add or remove container groups on its own. If you need more capacity, you or an external launcher create more groups. For automatic scaling, use a service such as Azure Container Apps or Kubernetes, or build scaling logic into your own automation.
ACI does not terminate secure connections for you. You can place Application Gateway or Front Door in front, or include a reverse proxy sidecar that handles certificates. For private access, deploy into a virtual network and expose the service through a gateway.
Write results to storage outside the group, such as an Azure Files share mounted as a volume, a storage account, or a database. Send logs to a Log Analytics workspace. Anything written only to the container’s own file system disappears with the group.
Prefer a managed identity and read secrets from Key Vault at run time, so no secret is stored in the image or deployment. If needed, use secret volumes or secure environment variables. Never bake secrets into images or put them in plain variables in templates.
Choose Container Apps when your workload is an always-on service that needs automatic scaling, ingress, revisions, and microservice features. Choose ACI when the container runs for a limited time, such as batch jobs, scripts, tests, or bursts, and you want the simplest possible way to run it.
The most common cause is the image pull: a wrong image name or tag, missing registry permissions, a registry firewall, or a very large image. Check the group’s events for the exact message, and also check regional quota and capacity. Smaller images in a nearby registry with identity-based access usually solve it.
26Summary and Key Takeaways
Azure Container Instances is the simplest way to run containers in Azure. You describe a container group with its images, CPU and memory, ports, volumes, identity, network, and restart policy, and Azure starts it in seconds on infrastructure you never manage. You pay by the second for the resources allocated, so short, bursty, and one-time workloads are very economical, while always-on services are better placed on platforms with scaling and routing built in. Choosing the right restart policy, keeping images small and trusted, using managed identities instead of stored secrets, saving results and logs outside the group, and cleaning up when finished are the habits that make ACI reliable and cheap. Remember its boundaries: no automatic scaling, no built-in load balancing or HTTPS, and many changes require recreating the group. Used for the jobs it was designed for, and combined with queues, workflows, and gateways where needed, ACI is a fast, flexible, and economical building block.
Key Takeaways
- Containers without servers — ACI runs container groups on demand, billed per second for allocated CPU and memory, with no virtual machines or clusters to manage.
- The container group is the unit — containers in a group share a host, lifecycle, network address, and volumes, which supports sidecars and init containers.
- Restart policy shapes the workload — use Never or OnFailure for jobs so billing stops when they finish, and Always only for services.
- Startup speed depends on the image — keep images small, use a private registry in the same region, and pull with a managed identity.
- Persist outside the group — write results to storage or databases and send logs to a workspace, because the group’s own disk and logs disappear on deletion.
- Secure by design — rely on platform isolation, trusted scanned images, managed identities, Key Vault, private networking, and gateways for anything public.
- Know the limits — ACI has no autoscaling, ingress, rolling updates, or built-in scheduler, so pair it with queues, workflows, and gateways, or choose Container Apps, App Service, or Kubernetes for always-on platforms.