Azure Container Instances: Run Containers Without Managing Servers

ACI versus other container options in Azure

ACI is not designed for long-running, load-balanced services. It has no built-in autoscaling, no traffic routing across multiple replicas, and no health-check-driven restarts that a production service needs. Think of ACI as a fast, lightweight way to run a container job — not as a web server platform.

Running your first container

Running a container with ACI takes one CLI command:

# Run a public container image — an NGINX web server
az container create \
  --resource-group my-rg \
  --name my-nginx \
  --image nginx:latest \
  --cpu 1 \
  --memory 1 \
  --ports 80 \
  --ip-address Public \
  --dns-name-label my-nginx-demo-$(date +%s)

Within 10–20 seconds, a container is running. The output includes a FQDN like my-nginx-demo-1234567890.eastus.azurecontainer.io. Open that in a browser to reach the NGINX default page.

# Check container status
az container show \
  --resource-group my-rg \
  --name my-nginx \
  --query "{status: instanceView.state, ip: ipAddress.ip, fqdn: ipAddress.fqdn}" \
  --output table

# View container logs
az container logs --resource-group my-rg --name my-nginx

# Delete the container
az container delete --resource-group my-rg --name my-nginx --yes

The best use case: batch and scheduled jobs

ACI’s strengths shine in batch processing. Consider a nightly data transformation job that takes an hour to run, then exits. Running this on a VM means the VM idles for 23 hours every day. ACI charges per second of actual container execution — you pay only while the job runs.

# Run a batch job container that exits when done
az container create \
  --resource-group my-rg \
  --name data-processor \
  --image myacr.azurecr.io/processor:latest \
  --cpu 2 \
  --memory 4 \
  --restart-policy Never \
  --environment-variables \
    STORAGE_ACCOUNT=mystorageaccount \
    INPUT_CONTAINER=raw-data \
    OUTPUT_CONTAINER=processed-data \
  --secure-environment-variables \
    STORAGE_KEY=<secret-key>

The —restart-policy Never flag means ACI does not restart the container after it exits. Combined with —restart-policy OnFailure for retry logic, this gives you simple job execution semantics: run the container, complete the job, clean up.

For a more production-ready approach, trigger ACI from Azure Logic Apps, Azure Data Factory, or an Azure Function on a schedule — rather than using the CLI directly. These orchestration services handle scheduling, retries, and alerting on failure.

Pulling images from a private registry

When your container image is in a private Azure Container Registry, ACI needs credentials to pull it. The recommended approach is to use a managed identity rather than a username/password:

# Create the container using a managed identity to pull from ACR
az container create \
  --resource-group my-rg \
  --name my-app \
  --image myacr.azurecr.io/myapp:latest \
  --cpu 1 \
  --memory 2 \
  --acr-identity /subscriptions/.../userAssignedIdentities/my-aci-identity \
  --assign-identity /subscriptions/.../userAssignedIdentities/my-aci-identity

The user-assigned managed identity needs the AcrPull role on the Azure Container Registry. See Azure Container Registry overview for how to set that up.

Container groups: multiple containers together

ACI supports container groups — a concept similar to Kubernetes pods. Multiple containers in a group share a network namespace (they communicate via localhost) and are scheduled on the same underlying host. Use container groups to run sidecars:

# container-group.yaml
apiVersion: 2021-09-01
name: my-container-group
type: Microsoft.ContainerInstance/containerGroups
location: eastus
properties:
  containers:
    - name: app
      properties:
        image: myacr.azurecr.io/myapp:latest
        resources:
          requests:
            cpu: 1
            memoryInGb: 1
        ports:
          - port: 8080
    - name: log-collector
      properties:
        image: myacr.azurecr.io/log-agent:latest
        resources:
          requests:
            cpu: 0.5
            memoryInGb: 0.5
  ipAddress:
    type: Public
    ports:
      - port: 8080
  osType: Linux

az container create --resource-group my-rg --file container-group.yaml

Limitations to know before committing

• No horizontal scaling. ACI runs a single container group. If you need multiple replicas with load balancing, use Azure Container Apps or AKS.
• No persistent local storage. The container’s local filesystem is ephemeral. Data written to the container’s disk is lost when the container stops. Mount an Azure Files share for persistence.
• Public IP per container group. ACI does not sit behind a shared load balancer by default. Each container group with a public IP gets its own IP address and DNS name. For multiple instances of the same service, use another compute option.
• No GPU support in all regions. ACI has limited GPU instance availability compared to VM-based options. Check GPU ACI availability in your target region before building on it.