Using Azure Container Instances

IntermediateTopic20 min5 min readAzure

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)

  1. Go to Azure Portal → Create → search Container Instances
  2. Provide a name (e.g. aci-01)
  3. Choose image source:
    • Azure Container Registry (select registry, image, tag)
    • Docker Hub / Quickstart image
  4. Set OS (Linux or Windows — auto-detected from image)
  5. Configure size: CPU cores, memory (GB), optional GPU (NVIDIA Tesla for ML)
  6. Networking:
    • Public: expose over a port (required for internet access)
    • Private: select VNet + subnet
  7. Advanced: restart policy, environment variables, command overrides
  8. 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

ServiceOrchestrationScalingComplexityBest for
ACINoneManual (redeploy)LowestSimple workloads, CI tasks
Container AppsAbstracted K8sAuto (scale to 0)MediumMicroservices, serverless
AKSFull KubernetesFull VMSSHighestEnterprise, 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

Hands-on: Run a Public Container Instance

Goal: Launch a simple container without managing a VM.

  1. Create resource group az104-containers-rg.
  2. Open Container instances > Create.
  3. Set container name az104-aci-demo.
  4. Use image mcr.microsoft.com/azuredocs/aci-helloworld.
  5. Set OS type Linux.
  6. Choose a small CPU and memory allocation.
  7. Set networking type Public.
  8. Expose port 80.
  9. Create the container group.
  10. Open the FQDN or public IP and confirm the sample app loads.
  11. Review container logs.
  12. Delete the container group when done.

Hands-on: Mount Azure Files into ACI

  1. Create a storage account and Azure Files share.
  2. Upload a test file to the share.
  3. Create a container instance.
  4. Add an Azure Files volume using the storage account name, key, and share name.
  5. Mount it inside the container at /mnt/share.
  6. Exec into the container or check logs to confirm the file is visible.

More in Microsoft Azure