Azure Container Instances
A beginner-friendly guide to running containers in Azure without managing any servers: what Container Instances are, how container groups work, how to network, store, secure, and watch them, and when to choose something else.
Imagine you need a small task done quickly, such as converting a batch of photos or running a short test. Renting and setting up a whole computer for a ten-minute job feels like hiring a full-time employee for one afternoon. What you really want is to say, “Run this program for me, give me the result, and bill me only for the minutes it ran.” Azure Container Instances were built for exactly this kind of need.
Containers have become a standard way to package and run software, but running them usually involves servers, clusters, and a lot of setup. Container Instances remove most of that. In this guide we start from zero, explain every new word the first time it appears, use everyday comparisons, and build up until you can use, design, and explain this service confidently in a project or an interview.
1First, What Is a Container?
You cannot understand the service without understanding the thing it runs.
A container is a lightweight package that holds an application together with everything it needs to run: its code, its libraries, its settings, and the tools it depends on. Because everything is inside the package, the application behaves the same way on your laptop, on a test server, and in the cloud. The classic complaint “it works on my machine but not on the server” mostly disappears.
A container image is the read-only template used to create containers, like a recipe or a blueprint. A container is a running copy made from that image. A container registry is a storage place for images, such as Docker Hub or Azure Container Registry, from which a platform can download an image to run it.
Think of a lunch box. Everything for the meal, the food, the cutlery, and the napkin, is packed inside, so you can eat anywhere and get the same meal. The image is the packed lunch box on a shelf. The running container is the box opened and being eaten. The registry is the shop shelf where lunch boxes are stored.
Containers versus virtual machines
A virtual machine pretends to be an entire computer, with its own full operating system inside. A container shares the operating system kernel of its host and only packages the application and its dependencies. This makes containers much smaller and much faster to start, often in seconds, while a virtual machine may take minutes.
| Question | Virtual machine | Container |
|---|---|---|
| What it contains | A full operating system plus applications | An application and its dependencies only |
| Start time | Minutes | Seconds |
| Size | Gigabytes | Usually megabytes to a few hundred megabytes |
| Isolation | Stronger, separate operating system | Lighter, shares the host kernel, though Azure adds extra isolation |
| Best for | Full control, older applications | Modern, portable, fast-starting applications |
2What Azure Container Instances Are
The simplest way to run a container in Azure.
Azure Container Instances, often shortened to ACI, is a service that lets you run containers in Azure without creating or managing any virtual machines or clusters. You give it an image, choose how much processing power and memory you want, and Azure starts the container, usually within seconds. When the work is done, you delete it and the billing stops.
ACI is described as serverless for containers. The word does not mean there are no servers at all. It means that you do not see, patch, or manage them. Microsoft handles the machines underneath, and you only deal with your containers.
Using ACI is like taking a taxi instead of buying a car. You do not worry about parking, servicing, or insurance. You hop in, travel the distance you need, and pay for the time you used. For a long daily commute, owning a car may be cheaper, and that is why other container services exist too.
ACI is about simplicity and speed for single containers or small groups. It is not a complete platform for large, complex applications, which usually need scaling, load balancing, and rollouts managed for them.
3The Problem ACI Solves
Running a container the traditional way carries a lot of baggage.
To run a container yourself, you normally need a machine, an operating system, a container engine installed on it, security updates, network setup, and monitoring. For a large system, teams also build a cluster, which is a group of machines managed together by an orchestrator such as Kubernetes. That is powerful but takes skill and time.
Many tasks do not need this weight. A nightly report, a quick test, a data conversion, or a small internal tool should not require a cluster. ACI gives you the container without the infrastructure around it.
Running containers yourself
- Provision and patch machines
- Install and update a container engine
- Pay for the machine even when idle
- Build scaling and monitoring on your own
Running containers on ACI
- No machines to manage
- Start in seconds from an image
- Pay per second only while running
- Logs and monitoring available through Azure
4Core Concept: The Container Group
The most important building block of ACI.
The top-level resource in ACI is the container group. A container group is a collection of one or more containers that are scheduled together on the same host machine. They start and stop together, share the same network address, can talk to each other through localhost, and can share storage volumes. If you know Kubernetes, a container group is very similar to a pod.
flowchart TD
CG["Container Group - one host, one shared lifecycle"] --> NET["Shared network - one IP address and port space"]
CG --> VOL["Shared volumes - Azure Files, empty directory, secrets"]
CG --> C1["Container 1 - main application"]
CG --> C2["Container 2 - sidecar for logging or sync"]
CG --> INIT["Init container - runs first and finishes"]
C1 |"localhost"| C2
C1 --> VOL
C2 --> VOL
INIT --> VOL
Why group containers together?
Some applications work best as a team of small programs. A common pattern is a sidecar, where a helper container runs next to the main one. The sidecar might collect logs, refresh files from a remote location, or add a secure connection. Because both live in the same group, they share the network and files, and the main container does not need to know how the helper works.
Init containers
An init container runs before the main containers and must finish successfully first. It is used for setup tasks, such as downloading a configuration file or preparing a folder. The main containers start only after init containers are done.
What is shared and what is not
| Item | Shared across the group? |
|---|---|
| Network address and ports | Yes, one IP address and one port space for all containers |
| Lifecycle | Yes, the group is created, started, stopped, and deleted as one unit |
| Volumes | Yes, if you mount them into several containers |
| CPU and memory | Requested per container, but the total for the group is what is billed |
| Container file system | No, each container has its own, which is lost when the container ends |
Because all containers in a group share one network address and port space, two containers in the same group cannot listen on the same port. Plan your ports carefully.
5How ACI Works Internally
What happens between asking for a container and seeing it run?
When you create a container group, your request goes to Azure Resource Manager, the central management service of Azure. It checks who you are, what you may do, and company rules. It then passes the order to the ACI service, which finds a host with enough free capacity. The host downloads your image from the registry, creates the containers, attaches the network and volumes, and starts them. Because hosts are prepared and shared, this often takes only seconds, though large images take longer to download.
sequenceDiagram
participant U as You or Pipeline
participant A as Azure Resource Manager
participant S as ACI Service
participant H as Host Machine
participant R as Container Registry
U->>A: Create container group
A->>A: Check identity, permissions, and policy
A->>S: Forward the request
S->>H: Reserve capacity on a host
H->>R: Pull the container image
R-->>H: Image downloaded
H->>H: Start init containers, then main containers
H-->>S: Report status Running
S-->>U: Provisioning succeeded, IP or name available
Isolation between customers
Many customers share the same physical hosts in Azure, so isolation matters. ACI is designed so that container groups from different customers are separated at the hypervisor level, which is stronger than ordinary container isolation. This gives the speed of containers with protection closer to that of virtual machines. Always read the current security documentation for the exact guarantees.
No persistent local storage
The file system inside a container is temporary. When a container group stops or is deleted, data written inside is lost. If you need to keep data, mount an external volume, such as an Azure Files share, or send results to a database or storage account.
6Creating a Container Instance Step by Step
The steps are the same whether you use the portal, the command line, or templates.
Choose subscription, resource group, and region
Pick where the container group lives, ideally near users or data, and check that the region supports the features you need.
Name the container group
Give it a clear name that shows its purpose, such as the project and task.
Select the image source
Choose a public sample, a private Azure Container Registry, or another registry, and supply sign-in details if required.
Set size
Choose the number of virtual CPUs and the amount of memory, starting small and growing only if needed.
Configure networking
Decide on a public address with a DNS name, or a private deployment into a virtual network, and open the needed ports.
Set restart policy and environment values
Choose how the container should behave when it ends, and provide settings, including secure values for secrets.
Review and create
Check the summary and create. When it shows Running, test the address or read the logs.
Choosing the size
You request vCPUs, which are virtual processor cores, and memory in gigabytes. Billing is based on these amounts multiplied by the seconds the group runs. There are upper limits per container group, which depend on region and operating system, and the limits can change. Check the current documentation to see what is available before planning a large job. If your work needs far more power, ACI may not be the right service.
Restart policies
Restart whenever it ends
Good for long-running services, such as a small web API that should stay up.
Restart only if it fails
Good for jobs that should retry on error but stop when they succeed.
Run once and stop
Good for one-time tasks, such as a conversion job, so the group ends when the work is done.
For batch jobs, choose a policy that lets the group finish and stop. A group that stays in the Running state keeps billing, even if the program inside is idle.
7The Life Cycle of a Container Group
Container groups move through clear states.
flowchart LR
CR["Created"] --> PU["Pulling image"]
PU --> RU["Running"]
RU --> SU["Succeeded - exited with success"]
RU --> FA["Failed - exited with an error"]
RU --> ST["Stopped - by you"]
FA --> RU2["Restarted per policy"]
SU --> DEL["Deleted - billing ends"]
FA --> DEL
ST --> DEL
| State | Meaning | Billing |
|---|---|---|
| Pending or creating | Azure is reserving capacity and pulling the image | Billing for compute starts when the containers begin running, so check the current rules |
| Running | The containers are up and doing work | Billed per second for CPU and memory |
| Succeeded | The container finished its work without an error | Compute billing stops once the containers stop |
| Failed | The container ended with an error | Depends on restart policy, and compute stops when no containers run |
| Stopped | You stopped the group | Compute stops, but the resource record remains until deleted |
Other costs, such as public IP addresses, storage for volumes, and registries, may continue after a group stops. Delete the whole resource group after testing so no small leftovers keep billing.
8Networking
How containers are reached, and how they reach others.
Public deployment
By default, a container group can receive a public IP address, and you may give it a DNS name label, which creates a friendly address inside an Azure domain for the region. You decide which ports and protocols to open. This is quick and perfect for tests, but exposing a service to the whole internet needs care.
Private deployment into a virtual network
For safer designs, you can deploy a container group into a virtual network, which is your own private network inside Azure. The group needs a dedicated delegated subnet, which is a slice of the network reserved for ACI. The container then receives a private address and can talk to databases, other servers, and on-site systems over private links, with no public exposure.
flowchart TD
USER["Internal users or services"] --> GW["Application Gateway or internal load balancer"]
GW --> SUB["Delegated subnet in a Virtual Network"]
SUB --> CG["ACI container group - private IP only"]
CG --> DBPE["Private endpoint"]
DBPE --> DB["Azure SQL Database"]
CG --> STG["Storage account with private endpoint"]
NSG["Network Security Group - allow and deny rules"] -.-> SUB
No built-in load balancer or scaling
ACI does not automatically create more copies of a container when traffic grows, and it does not offer a built-in load balancer across several groups. Each container group has its own address. If you need multiple copies behind one address, you place something such as Azure Application Gateway or a load balancer in front, or choose a service built for scaling.
Features such as network deployment options, supported regions, and outbound connection behavior have evolved over time. Always confirm current limits and settings in Microsoft’s documentation before finalizing a design.
9Storage and Data
Containers forget everything when they stop, so plan where data lives.
Empty directory volume
A scratch space shared by containers in the group while it runs. Gone when the group ends.
Azure Files share
A shared folder in a storage account that can be mounted into containers. Data survives after the group is deleted.
Secret volume
Places sensitive values, such as keys, into files that containers can read, without baking them into the image.
Git repository volume
Copies files from a repository into a volume when the group starts, useful for simple setups.
For results that must last, such as processed files or reports, many designs write output to Azure Blob Storage or a database. Keeping data outside the container makes the container disposable, which is a healthy habit in cloud design.
A container is like a hotel room. You can leave your notes on the desk during your stay, but the room is cleaned and reset when you check out. If you want to keep something, you must take it with you or store it in a locker at the front desk. Azure Files and Blob Storage are the locker.
10Security Best Practices
Containers are small, but the data they touch can be very valuable.
Protect the image
- Use trusted base images from reliable sources, and keep them updated, since old images may contain known weaknesses.
- Scan images for vulnerabilities before running them, using tools such as Microsoft Defender for Containers or scanners in your build pipeline.
- Use a private registry. Azure Container Registry keeps your images private and can integrate with Azure sign-in.
- Avoid secrets inside images. An image can be copied, and anything inside it travels with it.
Identity and secrets
A managed identity is an identity that Azure creates for a resource, so the container can prove who it is to services like Key Vault, Storage, or a database without a stored password. ACI supports managed identities for its container groups, and they can also be used to pull images from Azure Container Registry. For other sensitive values, use secure environment variables, which are hidden from the portal view, or a secret volume, and keep the original secrets in Azure Key Vault.
Network protection
- Prefer private deployment into a virtual network for internal workloads.
- Open only the ports you truly need.
- Use network security groups to allow or deny traffic.
- Place a web application firewall in front of anything public.
Access control
Use role-based access control to decide who can create, change, or delete container groups, and give only the least permission needed. Use Azure Policy to enforce company rules, such as requiring private networking or approved registries.
Special isolation options
Azure also offers confidential container options on ACI for sensitive workloads, which use hardware-based protection so that data stays encrypted even while being processed. Availability depends on region and changes over time, so verify the current status before relying on it.
A container running with a public address and weak settings can be found and attacked within minutes. Never leave test containers exposed to the internet with default passwords or open management ports.
11Monitoring, Logging, and Metrics
Even small containers need to be watched.
Logs are written records of what a program prints or reports. You can read container logs directly from the portal or from the command line, which is useful while testing. For serious use, send logs to a Log Analytics workspace in Azure Monitor, where you can search, keep them longer, and build alerts. Metrics are numbers over time, such as processor use and memory use, which ACI reports for each container group.
Container logs and events
Show output and lifecycle events, such as image pulls, starts, and crashes.
Connect and run commands
You can open a shell inside a running container for troubleshooting, in supported cases.
Liveness and readiness probes
Checks that call a path or run a command to see if a container is healthy and ready for traffic.
Azure Monitor alerts
Notify people when memory is too high, when a container restarts too often, or when a job fails.
What to watch
- Repeated restarts, which usually signal a crash or a bad setting.
- Memory use close to the limit, because the container may be stopped for exceeding it.
- Long image pull times, which suggest an oversized image or a slow registry.
- Job duration compared with normal, to catch slow or stuck tasks.
12Best Use Cases
ACI shines when work is short, simple, or bursty.
Batch jobs and data processing
A company starts a container each night to convert files, generate reports, or clean data. The job runs for twenty minutes, finishes, and the group ends. The company pays only for those minutes, with no idle machine.
Build and test agents
Pipelines can launch short-lived containers to run tests or build code, then discard them. Each run starts from a clean image, which makes results more reliable.
Simple internal tools and small APIs
A small team runs a lightweight internal tool or a low-traffic API in a container group, avoiding the work of setting up a web hosting plan or a cluster.
Event-driven tasks
When a file arrives or a message is sent, an automated workflow, such as an Azure Logic App or Function, starts a container to process it. The container runs once and disappears.
Quick experiments and demonstrations
Developers and trainers can launch a container in seconds to try a new tool, demo an application, or reproduce a problem, and then delete it.
Burst capacity for Kubernetes
Teams running Azure Kubernetes Service can use virtual nodes to send extra pods to ACI during traffic spikes, so they do not need to keep extra machines running all the time. Check the current status and supported versions of virtual nodes before depending on them.
flowchart TD
TRG["Trigger - schedule, message, or file upload"] --> AUTO["Automation - Logic App, Function, or pipeline"]
AUTO --> ACI["Create ACI container group - restart policy Never"]
ACI --> JOB["Container runs the job"]
JOB --> OUT["Write results to Blob Storage or database"]
JOB --> LOG["Send logs to Log Analytics"]
OUT --> DONE["Automation deletes the container group"]
13ACI Compared With Other Azure Compute Options
Azure offers several ways to run containers. Choose the right one.
| Service | What it is | Strength | Limitation |
|---|---|---|---|
| Container Instances | Serverless single containers and small groups | Fast start, per-second billing, simple | No built-in scaling, load balancing, or rollouts |
| Container Apps | Serverless platform for microservices and containers | Automatic scaling, including to zero, built-in ingress and revisions | More concepts to learn than ACI |
| App Service | Managed web hosting, with container support | Web features such as slots, certificates, and simple operations | Plan billing continues even when idle |
| Kubernetes Service (AKS) | Managed Kubernetes cluster | Full control, huge ecosystem, complex scaling | Needs skills and ongoing management |
| Virtual Machines | Rented computers | Full control of the system | You manage everything |
| Azure Functions | Event-driven small functions | Very simple event handling | Designed for functions, not general containers by default |
flowchart TD
START["I have a container to run"] --> Q1{"Is it a short job or a quick task?"}
Q1 -- Yes --> ACI["Container Instances"]
Q1 -- No --> Q2{"Does it need automatic scaling and many services?"}
Q2 -- Yes --> Q3{"Do you need full Kubernetes control?"}
Q3 -- Yes --> AKS["Kubernetes Service"]
Q3 -- No --> CA["Container Apps"]
Q2 -- No --> Q4{"Is it a web app with web features like slots?"}
Q4 -- Yes --> AS["App Service"]
Q4 -- No --> ACI2["Container Instances for a small steady service"]
This map is only a starting point. Team skills, cost, and requirements for scaling, networking, and compliance should decide the final choice. Many real systems combine services, such as Container Apps for the main application and ACI for occasional batch tasks.
14Pricing and Cost Control
Pay only for what runs, and watch the small extras.
ACI charges mainly for the vCPUs and memory that your container group uses, counted per second while it runs. Some options, such as special hardware or Windows containers, have different rates. Related services, including image registries, storage for volumes, public IP addresses, and network traffic leaving Azure, are billed separately. Rates differ by region and change over time, so use the Azure pricing calculator for estimates.
Great value for brief jobs
Ten minutes of compute costs only ten minutes, with no idle machine.
Can cost more than alternatives
A container that runs all day, every day, may be cheaper on a reserved virtual machine, an App Service plan, or Container Apps.
Request what you need
Oversized CPU and memory multiply the bill. Measure and adjust.
Delete finished groups
Remove stopped groups and related leftovers, and tag resources so owners are clear.
Compare the monthly cost of your steady workload on ACI against other services using the pricing calculator. The break-even point is often where a container runs more than a few hours each day.
Set a budget with alerts in Cost Management, and use tags, which are small name-and-value labels such as owner and project, to understand who spends what. Where available and suitable for non-critical, interruptible jobs, discounted spare-capacity options may also exist, so check the current offers.
15Reliability and Limitations
Know what ACI promises, and what it does not.
ACI is built for simplicity, not for every kind of resilience. A container group runs on one host. If that host has a problem, the group may be restarted elsewhere, but you cannot count on instant, seamless failover. For services that must stay up, you need extra design, such as running several groups in different availability zones, which are physically separate sites within a region, where the region supports it, and placing a load balancer or global entry point in front.
Advantages
- Very fast and simple to start
- No machines or clusters to manage
- Per-second billing for short jobs
- Container group model supports sidecars
- Private network deployment is possible
- Works well with automation tools
Limitations and trade-offs
- No built-in autoscaling or load balancing
- Resource size limits per group
- No persistent local storage
- Less suitable for large, complex systems
- Fewer web hosting features than App Service
- Feature and region availability can differ and change
The central trade-off
The trade-off is simplicity versus power. ACI gives you containers with almost no setup, but you give up the rich scaling, rollout, and traffic features of bigger platforms. If your needs are small and short, simplicity wins. If your needs grow, plan an upgrade path to Container Apps or Kubernetes early, and keep your images portable so the move is easy.
16Anti-Patterns to Avoid
Common mistakes that cause pain.
What it is
Using ACI as the only home for a large, critical, high-traffic system.
Why it hurts
Without built-in scaling, load balancing, and rollouts, you must build all of it yourself, and it becomes fragile.
Better approach
Use Container Apps, App Service, or Kubernetes for such workloads, and keep ACI for simple or bursty tasks.
What it is
Storing important results only inside the container’s own file system.
Why it hurts
When the container stops, the data disappears.
Better approach
Write results to Azure Files, Blob Storage, or a database before the job ends.
What it is
Leaving finished or forgotten container groups running with the restart policy set to Always.
Why it hurts
They keep billing for compute while doing nothing useful.
Better approach
Use Never or OnFailure for jobs, and have automation delete groups when work is complete.
What it is
Baking passwords, keys, or connection strings into the image or plain environment variables.
Why it hurts
Anyone who can pull the image or view the settings can read the secrets.
Better approach
Use managed identities, secure environment variables or secret volumes, and Azure Key Vault.
What it is
Using huge images or the “latest” tag for everything.
Why it hurts
Large images start slowly and cost more bandwidth, and the “latest” tag can silently change the version that runs, making problems hard to trace.
Better approach
Build small images, pin specific version tags or digests, and keep a clear release process.
“Serverless means my container can never fail or be moved.” Not true. Containers can crash, hosts can be replaced, and groups can be restarted. Design your jobs to be safe to repeat, which engineers call idempotent, so running one twice does no harm.
17Troubleshooting Common Problems
Most problems have simple causes.
| Symptom | Likely cause | What to try |
|---|---|---|
| Container stays in Waiting or image pull error | Wrong image name or tag, or missing registry permission | Check the name, tag, and registry credentials or managed identity role |
| Container starts then exits immediately | The program finishes at once, or crashes at startup | Read the logs, and make sure the container has a long-running process if it should stay up |
| Restarts again and again | Crash loop caused by a bad setting or too little memory | Check logs, environment values, and memory limits |
| Cannot reach the container address | Port not exposed, firewall rule, or private network only | Verify ports, security rules, and whether the group has a public or private IP |
| Cannot connect to a database | Network rules, missing private link, or wrong credentials | Check virtual network placement, firewall rules, and identity permissions |
| Quota or capacity error | Regional limits or no capacity for the requested size | Request a quota increase, reduce the size, or choose another region |
| Data missing after restart | Data was written to the container file system | Use a mounted volume or external storage |
| Unexpected bill | Forgotten running groups, large sizes, or other attached services | Review Cost Management, delete leftovers, and set budgets |
18Best Practices Checklist
A short list for your next project.
- Use ACI for the right jobs. Choose it for short, simple, or bursty tasks, and pick other services for large steady systems.
- Keep images small and pinned. Use minimal base images and specific version tags.
- Use a private registry with managed identity for pulling images.
- Keep containers stateless. Store data in Azure Files, Blob Storage, or a database.
- Pick the correct restart policy. Never or OnFailure for jobs, Always for services.
- Protect secrets. Use managed identities, Key Vault, and secure variables.
- Deploy privately into a virtual network when the workload is internal.
- Send logs to Log Analytics and alert on restarts and failures.
- Describe deployments in templates or code so they are repeatable.
- Make jobs safe to repeat. Design for retries without side effects.
- Tag and budget. Label resources with owner and project, and set cost alerts.
- Clean up. Delete finished groups and related resources.
19Real-World Stories
How different teams use ACI.
A media company converting videos
A company receives uploaded videos throughout the day. Each upload triggers an automated workflow that launches a container to convert the video, saves the result to storage, and deletes the container. Costs follow the amount of work, with nothing running overnight.
A software team with test pipelines
A development team starts temporary containers for test runs in its pipeline. Every run is clean and isolated, and finished containers are removed automatically, which saves maintenance and money.
A finance team with nightly reports
An accounting department schedules a container to pull data, generate reports, and write them to a secured file share each night. The container runs privately in a virtual network and uses a managed identity to reach the database.
A large retailer bursting from Kubernetes
A retailer running Kubernetes uses burst capacity into ACI during sales, so the main cluster does not need extra machines all year. Planning and testing of this pattern is important, and teams check the current supported approach in Microsoft’s documentation.
20Frequently Asked Questions
21Summary and Key Takeaways
Key Takeaways
- ACI runs containers without servers to manage. You provide an image and a size, Azure starts it in seconds, and you pay per second for the CPU and memory used while it runs.
- The container group is the core unit. Containers in a group share a host, a network address, a lifecycle, and optional volumes, and patterns such as sidecars and init containers fit naturally.
- Plan for temporary storage and restarts. The container file system disappears, so keep data in Azure Files, Blob Storage, or a database, choose the right restart policy, and make jobs safe to repeat.
- Secure the whole path. Use trusted, scanned images from a private registry, managed identities and Key Vault for secrets, private deployment into a virtual network, and least-privilege access.
- Know the limits. ACI has no built-in autoscaling or load balancing and has size limits, so use Container Apps, App Service, or Kubernetes for larger or steadier systems.
- Watch, clean up, and control cost. Send logs and metrics to Azure Monitor, alert on restarts and failures, delete finished groups, tag resources, and compare steady workloads against other services, since ACI shines for short, simple, or bursty work.