Using Azure Container Instances
Run Docker containers in Azure without managing infrastructure using Azure Container Instances — container groups, networking options, storage, and limitations.
What Are Azure Container Instances?
Azure Container Instances (ACI) is a PaaS container hosting solution — similar in concept to a Docker host, but fully managed by Azure. You run one or more containers without managing any underlying VMs or cluster infrastructure.
Key characteristics:
- No orchestration complexity (unlike AKS)
- Pull images from Azure Container Registry, Docker Hub, or other registries
- Pay per second of CPU and memory used
- Best for: simple workloads, batch jobs, testing, dev/CI pipelines
Container Groups
A container group is the fundamental unit of deployment in ACI — a logical collection of containers that are scheduled together on the same host.
What a container group provides:
- Shared lifecycle — all containers start and stop together
- Shared local network — containers communicate over
localhost - Shared storage — all containers in the group mount the same Azure Files share
Container Group
├── Container 1 (e.g. web app)
└── Container 2 (e.g. logging sidecar)
└── Shared: lifecycle + network + Azure Files storage
Multiple container groups are isolated from each other — they have separate underlying infrastructure.
Networking
Public access
- Assign a public IP address with an FQDN
- Port must be explicitly exposed (e.g. port 80 for HTTP)
- Accessible from the internet via the FQDN
Private access
- Deploy into a VNet subnet
- Accessible only from within the VNet (and peered/on-prem networks)
- No public IP assigned
Storage: Azure Files
Containers in a group share Azure Files for persistent storage:
- Mount a file share into one or more containers
- Data persists after the container stops or restarts
- Use for: shared configuration, logs, databases
Creating a Container Instance (Portal Steps)
- Go to Azure Portal → Create → search Container Instances
- Provide a name (e.g.
aci-01) - Choose image source:
- Azure Container Registry (select registry, image, tag)
- Docker Hub / Quickstart image
- Set OS (Linux or Windows — auto-detected from image)
- Configure size: CPU cores, memory (GB), optional GPU (NVIDIA Tesla for ML)
- Networking:
- Public: expose over a port (required for internet access)
- Private: select VNet + subnet
- Advanced: restart policy, environment variables, command overrides
- Review + Create
Scaling Limitation (Critical Exam Point)
ACI cannot scale after deployment.
Once a container group is running:
- You cannot add or remove container instances
- You cannot change CPU or memory
- To resize: you must stop and redeploy with new settings
Best practice: Use IaC (ARM templates or Bicep) to define the container group so it can be easily redeployed with updated sizing.
Monitoring Containers
From the Container Instance resource:
- Containers tab → view lifecycle events (pull, start, stop)
- Logs tab → view stdout/stderr from running containers
- Overview → shows public IP, FQDN, provisioning status
ACI vs. Other Container Services
| Service | Orchestration | Scaling | Complexity | Best for |
|---|---|---|---|---|
| ACI | None | Manual (redeploy) | Lowest | Simple workloads, CI tasks |
| Container Apps | Abstracted K8s | Auto (scale to 0) | Medium | Microservices, serverless |
| AKS | Full Kubernetes | Full VMSS | Highest | Enterprise, full control |
Key Exam Takeaways
- ACI = PaaS Docker-like runtime; no VM management
- Container group = unit of deployment; shared lifecycle, network, and storage
- Azure Files provides shared persistent storage for containers in a group
- Public ACI requires an exposed port; private ACI uses a VNet subnet
- ACI cannot scale — must redeploy to change size
- Use IaC (ARM/Bicep) for ACI to simplify redeploys
- Container images pulled from ACR, Docker Hub, or other registries
Quick Revision Cheat Sheet
ACI = managed Docker host (PaaS)
Container group = smallest deployable unit
Group shares: lifecycle + local network + Azure Files
Public: needs exposed port + IP
Private: deployed into VNet subnet
No scaling after deployment → redeploy to resize
Use IaC for easy redeploy
Pull images from ACR / Docker Hub
Reference Documentation
- Azure Container Instances overview
- Container groups in ACI
- VNet scenarios for ACI
- Mount Azure Files in ACI
- Use ACR with ACI
Hands-on: Run a Public Container Instance
Goal: Launch a simple container without managing a VM.
- Create resource group
az104-containers-rg. - Open Container instances > Create.
- Set container name
az104-aci-demo. - Use image
mcr.microsoft.com/azuredocs/aci-helloworld. - Set OS type Linux.
- Choose a small CPU and memory allocation.
- Set networking type Public.
- Expose port
80. - Create the container group.
- Open the FQDN or public IP and confirm the sample app loads.
- Review container logs.
- Delete the container group when done.
Hands-on: Mount Azure Files into ACI
- Create a storage account and Azure Files share.
- Upload a test file to the share.
- Create a container instance.
- Add an Azure Files volume using the storage account name, key, and share name.
- Mount it inside the container at
/mnt/share. - Exec into the container or check logs to confirm the file is visible.
