Cloud & IT Cert Prep · Lesson

Azure Container Instances

Launch a containerised application in seconds using ACI without managing servers, configure environment variables and volume mounts, and understand ACI billing.

Azure Container Instances is a free Cloud & IT Cert Prep lesson on CoddyKit — lesson 2 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Cloud & IT Cert Prep learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.

What Is Azure Container Instances?

Azure Container Instances (ACI) is the fastest way to run a containerised workload in Azure without managing any servers or orchestrators. You provide a container image, and Azure runs it in seconds on shared, multi-tenant infrastructure. ACI is ideal for short-lived tasks, batch jobs, build agents, and event-driven workloads where spinning up a full Kubernetes cluster would be excessive overhead.

Creating a Container Instance

Launch an ACI container with a single az container create command. Specify the image, resource group, CPU, and memory. ACI pulls the image, allocates resources, and starts the container — typically within 5-10 seconds. Each container instance gets a unique fully qualified domain name (FQDN) if you assign a DNS name label, making it immediately accessible from the internet.

# Run an Nginx container accessible from the internet
az container create \
  --name my-nginx \
  --resource-group MyRG \
  --image nginx:latest \
  --cpu 1 \
  --memory 1 \
  --dns-name-label my-nginx-demo \
  --ports 80

# Access at: http://my-nginx-demo.<region>.azurecontainer.io

Environment Variables and Secure Values

Pass configuration to ACI containers using environment variables specified at creation time. For sensitive values such as API keys or passwords, use secure environment variables — these are not shown in the Azure portal or CLI output after deployment, preventing accidental exposure in logs or audit trails. Secure values are still accessible inside the container at runtime as normal environment variables.

# Pass regular and secure environment variables
az container create \
  --name my-app \
  --resource-group MyRG \
  --image mycontainerregistry.azurecr.io/myapp:v1.0 \
  --environment-variables APP_ENV=production \
  --secure-environment-variables \
    DATABASE_PASSWORD='super-secret-password' \
    API_KEY='my-api-key'

# View logs from the running container
az container logs --name my-app --resource-group MyRG

ACI Billing and Resource Allocation

ACI bills by the second based on the CPU cores and memory GB you allocate, with no minimum billing period. You only pay while the container is running — the moment it stops, billing stops. This makes ACI extremely cost-effective for short-lived workloads. You can allocate between 0.1 and 4 CPU cores and 0.1 to 16 GB of memory per container group, in supported combinations.

# Small: 0.5 CPU, 0.5 GB memory
az container create --name small-task --resource-group MyRG \
  --image my-batch-image:latest --cpu 0.5 --memory 0.5 \
  --restart-policy Never  # Don't restart after completion

# Large: 4 CPU, 16 GB memory for intensive tasks
az container create --name ml-inference --resource-group MyRG \
  --image ml-model:latest --cpu 4 --memory 16

Restart Policies

ACI supports three restart policies that control container behaviour after it exits. Always (default) restarts the container whenever it exits — suitable for long-running services. Never runs the container once and leaves it in a terminated state — ideal for batch jobs. OnFailure restarts only when the container exits with a non-zero exit code — useful for retry-on-error patterns.

# Batch job: run once, never restart
az container create \
  --name data-processor \
  --resource-group MyRG \
  --image my-batch-image:latest \
  --restart-policy Never \
  --environment-variables BATCH_DATE=2025-01-01

# Check the container's final state
az container show \
  --name data-processor \
  --resource-group MyRG \
  --query '{state:instanceView.state, exitCode:instanceView.currentState.exitCode}'

Container Groups: Multi-Container Deployments

A container group is a collection of containers that share a lifecycle, network, and storage — similar to a Kubernetes pod. Containers in the same group share a local IP address and port namespace, allowing them to communicate via localhost. A common pattern is a main application container and a sidecar container (e.g., a logging agent or proxy) in the same group, defined with a YAML or ARM template.

# multi-container.yaml
apiVersion: '2021-09-01'
location: eastus
name: my-container-group
properties:
  containers:
  - name: app
    properties:
      image: myapp:v1.0
      ports: [{port: 80}]
      resources: {requests: {cpu: 1, memoryInGb: 1}}
  - name: log-forwarder
    properties:
      image: fluent-bit:latest
      resources: {requests: {cpu: 0.5, memoryInGb: 0.5}}
  osType: Linux
  restartPolicy: Always
type: Microsoft.ContainerInstance/containerGroups

# Deploy from YAML
# az container create --resource-group MyRG --file multi-container.yaml

Volume Mounts: Azure Files Integration

ACI containers are stateless by default — data written to the container's filesystem is lost when the container restarts. Mount an Azure Files share as a volume to persist data across container restarts or share data between containers in the same group. Specify the storage account name, key, and file share name when creating the container instance.

# Mount an Azure Files share for persistent storage
az container create \
  --name stateful-app \
  --resource-group MyRG \
  --image myapp:v1.0 \
  --azure-file-volume-account-name mystorageaccount \
  --azure-file-volume-account-key '<storage-account-key>' \
  --azure-file-volume-share-name myfileshare \
  --azure-file-volume-mount-path /data

# Data written to /data persists in the Azure Files share

GPU Container Instances

ACI supports GPU container instances (K80, V100) for ML inference, video processing, and scientific computation workloads. GPU instances are available in selected regions and require Linux containers. They are billed per GPU/second, making them economical for burst inference scenarios where you spin up a GPU container, run the model, and immediately tear it down — much cheaper than a dedicated GPU VM running 24/7.

# Create a GPU-enabled container instance
az container create \
  --name gpu-inference \
  --resource-group MyRG \
  --image my-ml-model:latest \
  --gpu-count 1 \
  --gpu-sku V100 \
  --cpu 4 \
  --memory 16 \
  --os-type Linux

ACI with Virtual Network

Deploy ACI container groups into a dedicated subnet within a VNet to give them private IP addresses and allow them to reach other VNet-connected resources (databases, VMs) without exposing them to the internet. VNet-integrated ACI requires a dedicated, delegated subnet (delegated to Microsoft.ContainerInstance/containerGroups) and does not support public IP assignment.

# Create an ACI container in a VNet
az container create \
  --name private-task \
  --resource-group MyRG \
  --image myapp:v1.0 \
  --vnet MyVNet \
  --subnet ContainerSubnet \
  --restart-policy Never

# The container gets a private IP from the subnet CIDR
# It can reach VNet resources (SQL, Redis, VMs) on private IPs

ACI as a Virtual Kubelet Node

ACI integrates with AKS as a virtual node via the Virtual Kubelet open-source project. When an AKS cluster experiences burst demand that exceeds its VM node capacity, Kubernetes can schedule pods onto a virtual ACI node — spinning up real ACI container instances. This provides infinite burst scaling without pre-provisioning extra VM nodes, and you only pay for the ACI compute during the burst period.

# Enable virtual nodes on an AKS cluster
az aks enable-addons \
  --name myAKSCluster \
  --resource-group MyRG \
  --addons virtual-node \
  --subnet-name VirtualNodeSubnet

# Schedule a burst pod on ACI via node selector
# spec:
#   nodeSelector:
#     kubernetes.io/role: agent
#     beta.kubernetes.io/os: linux
#     type: virtual-kubelet
#   tolerations:
#   - key: virtual-kubelet.io/provider
#     operator: Exists

When to Use ACI vs AKS vs App Service

Choose ACI for short-lived tasks, batch jobs, CI build agents, and one-off containers where Kubernetes overhead is unnecessary. Choose AKS for long-running, multi-container microservices requiring service discovery, health checks, rolling updates, and cluster networking. Choose App Service when you want PaaS conveniences (deployment slots, managed certs, built-in auth) without managing container networking yourself.

Quick Check

Test your understanding of Microsoft Azure Fundamentals (AZ-900) concepts from this lesson.

Lesson Recap

In this lesson you learned: Azure Container Instances run containers in seconds without server management, billed per second of CPU and memory, container groups allow multiple containers to share network and storage like a Kubernetes pod, and restart policies (Always, Never, OnFailure) control container lifecycle after exit. Next up we explore Kubernetes concepts for Azure.

Frequently asked questions

Is the “Azure Container Instances” lesson free?

Yes — the full text of “Azure Container Instances” is free to read here on the web, and the Cloud & IT Cert Prep course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Cloud & IT Cert Prep course, upgrade to CoddyKit PRO.

What will I learn in “Azure Container Instances”?

Launch a containerised application in seconds using ACI without managing servers, configure environment variables and volume mounts, and understand ACI billing. You practise Cloud & IT Cert Prep with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.

Do I need any experience to start Cloud & IT Cert Prep?

No prior experience is required. Cloud & IT Cert Prep on CoddyKit is structured for beginners through advanced learners; this is — lesson 2 of 4, so you can start here or from the beginning and move at your own pace.

How long does the “Azure Container Instances” lesson take?

Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.

Can I write and run code in this Cloud & IT Cert Prep lesson?

Yes. Every Cloud & IT Cert Prep lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.

All lessons in this course

← Back to Cloud & IT Cert Prep