Azure Container Instances

Azure Kubernetes Service is powerful but comes with complexity — clusters, node pools, deployments, and services require planning and management. Sometimes a single container just needs to run quickly and be done. Azure Container Instances (ACI) is the simplest and fastest way to run a container in Azure — without managing any servers, clusters, or infrastructure at all.

What is Azure Container Instances?

ACI is a serverless container service. A Docker container image is specified, and ACI runs it immediately — no virtual machines, no Kubernetes cluster, no node pools to set up. It is the fastest path from a container image to a running container in the cloud.

ACI vs AKS Comparison

Container Groups

The top-level resource in ACI is the Container Group — a collection of containers scheduled together on the same host machine. Containers in the same group share the same lifecycle, network (same IP address and port space), and storage volumes. This is similar to a Kubernetes Pod.

Diagram – Container Group with Multiple Containers

  Container Group: my-app-group
  Public IP: 20.50.10.5
  │
  ├── Container 1: web-frontend
  │   Image: myacr.azurecr.io/frontend:v2
  │   Port: 80 (exposed to internet)
  │   CPU: 1 core, RAM: 1.5 GB
  │
  ├── Container 2: log-sidecar
  │   Image: fluent/fluentd:latest
  │   (No public port — collects logs from Container 1)
  │   CPU: 0.5 core, RAM: 0.5 GB
  │
  └── Shared Volume: /app/logs  (both containers access this)

Running a Container with ACI

Using Azure CLI

  # Run a public Docker image (nginx web server)
  az container create \
    --resource-group myRG \
    --name my-nginx \
    --image nginx:latest \
    --ports 80 \
    --dns-name-label my-nginx-demo \
    --location eastus

  # Check status
  az container show \
    --resource-group myRG \
    --name my-nginx \
    --query "{Status:instanceView.state, FQDN:ipAddress.fqdn}"

  # Output:
  # Status: Running
  # FQDN: my-nginx-demo.eastus.azurecontainer.io

  # View container logs
  az container logs \
    --resource-group myRG \
    --name my-nginx

Using a Private Registry (Azure Container Registry)

  az container create \
    --resource-group myRG \
    --name my-private-app \
    --image myacr.azurecr.io/myapp:v1.0 \
    --registry-login-server myacr.azurecr.io \
    --registry-username myACRUser \
    --registry-password myACRPassword \
    --ports 8080 \
    --cpu 2 \
    --memory 4

Use Cases for ACI

Batch Processing Jobs

ACI is ideal for running a containerized batch job that processes data and exits. The container runs, finishes its task, and billing stops immediately — no idle VM costs.

  Example: Process 10,000 images for thumbnail generation
  → Start ACI container with image-processing code
  → Container reads images from Blob Storage
  → Generates thumbnails
  → Writes results back to Blob Storage
  → Container exits automatically
  → Billing: 3 minutes × per-second rate = very low cost

CI/CD Pipeline Tasks

Azure DevOps and GitHub Actions can use ACI containers as build agents — spinning up on-demand for pipeline runs and tearing down immediately after, avoiding the cost of always-on build servers.

Testing and Development

Quickly run a database container (MySQL, PostgreSQL) or a test environment for integration testing, then delete it when done.

Event-Driven Burst Workloads

AKS clusters can use ACI as a "virtual node" via the Virtual Kubelet. When the cluster needs more capacity quickly (burst), pods overflow onto ACI instead of waiting for new cluster nodes to provision — providing instant scale.

Persistent Storage with ACI

Containers are stateless by default — all data is lost when the container stops. ACI can mount persistent volumes so data survives container restarts:

• Azure Files Share: Mount an Azure Files SMB share as a volume inside the container.
• Azure Disk: Mount an Azure managed disk (available in single-container groups only).
• Empty Dir: A temporary volume shared between containers in the same group — cleared when the group stops.

Networking Options

ACI Pricing

ACI billing is per second based on the vCPU and memory allocated to the container group:

• Charged from the time the container starts to when it stops (or is deleted).
• Separate rates for vCPU-seconds and memory (GB)-seconds.
• No charge for provisioning time — only actual running time.
• First 180,000 vCPU-seconds and 360,000 GB-seconds per month are free.

Key Takeaways

• ACI runs Docker containers instantly without managing any VMs, clusters, or infrastructure.
• A Container Group is the top-level resource — similar to a Kubernetes Pod — that can hold multiple containers sharing the same IP and volumes.
• ACI is ideal for batch jobs, CI/CD tasks, short-lived testing environments, and burst capacity overflow from AKS.
• Containers can mount Azure Files shares for persistent storage that survives container restarts.
• Billing is per second of actual CPU and memory used — making ACI very cost-efficient for short-lived workloads.