This chapter covers Azure Container Instances (ACI) and Azure Kubernetes Service (AKS), two core container services on Azure. For AZ-900, these services fall under Objective 2.2: 'Describe core Azure services,' and they appear in roughly 5-10% of exam questions. Understanding when to use ACI versus AKS—and how they differ from virtual machines—is critical for passing. We'll explore the business problems containers solve, how each service works, and the exam traps candidates frequently fall into.
Jump to a section
Imagine you run a global shipping company. You need to transport goods from factories to stores. Traditional shipping uses entire cargo ships dedicated to one factory's products—that's like a virtual machine (VM). Each ship has its own crew, fuel, and maintenance, even if it's only half full. Now think of containers: standardized steel boxes that can hold any factory's goods. A single cargo ship can carry hundreds of containers, each isolated but sharing the ship's crew and engine. Azure Container Instances (ACI) is like renting individual containers for urgent shipments—you pay per container per day, no long-term ship lease. Azure Kubernetes Service (AKS) is like a shipping port authority that automatically decides which containers go on which ships, balances load, and reroutes during storms. Just as containers revolutionized shipping by standardizing and maximizing efficiency, software containers package code with its dependencies, running consistently across any environment. ACI launches a container in seconds without managing servers; AKS orchestrates hundreds of containers across clusters, handling scaling, updates, and failures. The mechanism: containers share the host OS kernel but have isolated filesystems and resource limits—like containers on a ship sharing the hull but not mixing cargo.
What Are Containers and Why Do They Matter?
Containers are lightweight, portable units that package application code with all its dependencies (libraries, configuration files, binaries). Unlike virtual machines, which each run a full guest operating system, containers share the host machine's OS kernel. This makes them far more efficient: you can run dozens of containers on a single VM, with faster startup times (seconds vs. minutes) and lower resource overhead. For businesses, this means faster deployment, easier scaling, and consistent behavior across development, testing, and production environments.
The Business Problem: Microservices and Scalability
Traditional monolithic applications run on a single server. If one component fails or needs updating, the entire app may go down. Modern applications are often built as microservices—small, independent services that communicate via APIs. Each microservice can be developed, deployed, and scaled independently. Containers are the ideal host for microservices because they are isolated, portable, and lightweight.
Azure Container Instances (ACI): The Simplest Way to Run a Container
ACI is a PaaS (Platform as a Service) offering that lets you run a single container in the cloud without managing any underlying infrastructure. You don't provision VMs, configure networking, or patch OS updates. You simply specify the container image (from Docker Hub or Azure Container Registry), allocate CPU and memory, and ACI launches the container in seconds.
How ACI Works: - You create a container group (a group of containers that share the same lifecycle and network). - You specify the image, resource limits (CPU cores and memory), and restart policy (Always, OnFailure, or Never). - Azure places the container on a host machine, isolates it using Hyper-V technology (secure containers), and provides a public IP address or a virtual network integration. - You are billed per second of container runtime, plus any storage attached.
Key Components: - Container Group: The top-level resource. All containers in a group are scheduled on the same host and share a network namespace, IP address, and storage volumes. - Image: The container image from a registry like Docker Hub or Azure Container Registry (ACR). - Resource Limits: You specify CPU (up to 4 cores) and memory (up to 16 GB) per container group. - Restart Policy: Controls whether the container restarts after it exits. - Environment Variables: Used to pass configuration data. - Volumes: Mount Azure Files shares or other storage for persistent data.
Pricing: ACI charges per second of runtime, with separate rates for CPU and memory. You also pay for the storage used by the container image and any mounted volumes. There is no upfront cost or long-term commitment.
When to Use ACI: - Simple, single-container applications (e.g., a batch job, a simple web app). - Event-driven workloads (e.g., process a file when it's uploaded to Blob Storage). - Quick testing or development environments. - Burst capacity for existing Kubernetes clusters (you can run ACI on virtual nodes in AKS).
Azure Kubernetes Service (AKS): Orchestrating Multiple Containers
AKS is a managed Kubernetes service. Kubernetes is an open-source container orchestration platform that automates deploying, scaling, and managing containerized applications. AKS simplifies Kubernetes management by handling the control plane (the master nodes) for free—you only pay for the worker nodes (VMs).
How AKS Works: - You create an AKS cluster, which consists of a control plane and one or more node pools. - The control plane is managed by Azure: it handles scheduling, API server, and etcd (key-value store). You do not have direct access to it. - Node pools are groups of VMs (called nodes) that run your containers. You can have multiple node pools with different VM sizes or even different OS types (Linux, Windows). - You deploy your application using Kubernetes manifests (YAML files) that define pods, services, deployments, and other resources. - Kubernetes schedules pods (groups of one or more containers) onto nodes based on resource requirements and constraints. - AKS integrates with Azure networking, monitoring, and security services.
Key Components: - Cluster: The entire Kubernetes environment, including control plane and nodes. - Node: A VM that runs your containers. Nodes are part of a node pool. - Pod: The smallest deployable unit in Kubernetes. A pod can contain one or more containers that share storage and network. - Service: An abstraction that exposes a set of pods as a network service (e.g., load balancer). - Deployment: A declarative definition of how to run and update your application (e.g., number of replicas, update strategy). - Namespace: A virtual cluster within a physical cluster, used to organize resources. - Azure Container Registry (ACR): A private registry for storing and managing container images used by AKS.
Pricing: You pay for the VMs in your node pools (compute, storage, networking). The control plane is free. You also pay for any additional Azure services you integrate (e.g., Azure Load Balancer, Azure Monitor).
When to Use AKS: - Multi-container applications with complex microservices architectures. - Applications that need automatic scaling, rolling updates, and self-healing. - Teams that need fine-grained control over deployment and scaling policies. - Production workloads with high availability and disaster recovery requirements.
Comparing ACI and AKS
| Feature | ACI | AKS | |---------|-----|-----| | Management overhead | None – fully managed | Low – Azure manages control plane; you manage nodes | | Startup time | Seconds | Minutes (nodes must be provisioned) | | Scaling | Manual or via Azure Functions | Automatic (Horizontal Pod Autoscaler, Cluster Autoscaler) | | Multi-container | Limited to container group (same host) | Full orchestration across nodes | | Pricing | Per second | Per VM hour | | Use case | Simple, burst, event-driven | Complex, production, microservices |
On-Premises Equivalent
On-premises, you would manage your own Kubernetes cluster using tools like kubeadm or Red Hat OpenShift. You would need to provision servers, install Kubernetes, configure networking, and handle upgrades and failures yourself. ACI has no direct on-premises equivalent; it's a cloud-native service that leverages Azure's infrastructure to run containers instantly.
Azure Portal and CLI Touchpoints
Azure Portal: - ACI: Navigate to 'Container instances' and click 'Create.' You'll fill in image, resource size, networking, and advanced settings. - AKS: Navigate to 'Kubernetes services' and click 'Create.' You choose cluster preset (e.g., Dev/Test, Production), node size, node count, and networking options.
Azure CLI:
Create an ACI container group:
az container create --resource-group myRG --name mycontainer --image mcr.microsoft.com/azuredocs/aci-helloworld --cpu 1 --memory 1.5 --ports 80 --dns-name-label mycontainer-dnsCreate an AKS cluster:
az aks create --resource-group myRG --name myAKSCluster --node-count 3 --enable-addons monitoring --generate-ssh-keysGet credentials to connect kubectl:
az aks get-credentials --resource-group myRG --name myAKSClusterDeploy an application to AKS:
kubectl create deployment hello-world --image=mcr.microsoft.com/azuredocs/aci-helloworld
kubectl expose deployment hello-world --type=LoadBalancer --port=80Create an ACI Container Group
In the Azure portal, search for 'Container instances' and click 'Create.' Fill in the basics: subscription, resource group, container name, region, and image source (e.g., Docker Hub or ACR). For a quick test, use the sample image 'mcr.microsoft.com/azuredocs/aci-helloworld.' Specify CPU (e.g., 1 core) and memory (e.g., 1.5 GB). Under networking, set the DNS name label and port (e.g., port 80). Optionally, add environment variables, volumes, or restart policy. Review and create. Behind the scenes, Azure allocates a host, pulls the image, and starts the container. Within 30 seconds, you'll have a running container with a public URL.
Monitor and Access ACI Container
After creation, navigate to the container instance in the portal. The 'Overview' blade shows the container state (Running, Stopped, etc.), IP address, and FQDN. Click 'Logs' to see stdout/stderr from the container. Use 'Events' to view lifecycle events (e.g., pulling image, started). You can also start/stop/restart the container from the portal. For CLI users, use 'az container logs' and 'az container attach' to stream logs. The container runs until you stop it or it exits based on restart policy. You are billed per second while it runs. This step is crucial for verifying the application works as expected.
Create an AKS Cluster
In the Azure portal, search for 'Kubernetes services' and click 'Create.' Choose a resource group, cluster name, and region. Select a preset configuration (e.g., Dev/Test for cost savings) or customize. Under 'Node pools,' specify the node size (e.g., Standard_DS2_v2) and initial node count (e.g., 3). Enable features like virtual nodes (to use ACI for burst scaling), Azure Policy, or container monitoring. Set networking (e.g., Azure CNI for advanced networking or kubenet for basic). Configure authentication (e.g., system-assigned managed identity). Review and create. Azure provisions the control plane (free) and worker nodes (VMs) in about 5-10 minutes. You'll get a kubeconfig file to connect kubectl.
Deploy an Application to AKS
First, get credentials using 'az aks get-credentials --resource-group myRG --name myAKSCluster'. This merges the cluster's kubeconfig into your local file. Then, create a deployment: 'kubectl create deployment hello-world --image=mcr.microsoft.com/azuredocs/aci-helloworld'. This creates a pod with the container. To expose it externally, run 'kubectl expose deployment hello-world --type=LoadBalancer --port=80'. AKS creates a public IP via Azure Load Balancer. Check the external IP with 'kubectl get service'. Behind the scenes, Kubernetes schedules the pod onto a node, pulls the image, and starts the container. The LoadBalancer service provisions an Azure load balancer and assigns a public IP. You can scale the deployment with 'kubectl scale deployment hello-world --replicas=5'.
Scale and Update the Application
AKS supports both manual and automatic scaling. For manual scaling, use 'kubectl scale deployment hello-world --replicas=10'. For automatic scaling, enable the Horizontal Pod Autoscaler (HPA): 'kubectl autoscale deployment hello-world --cpu-percent=50 --min=3 --max=10'. HPA monitors CPU (or custom metrics) and adjusts replicas. To update the application, change the image tag in the deployment (e.g., 'kubectl set image deployment/hello-world hello-world=myimage:v2'). Kubernetes performs a rolling update, gradually replacing old pods with new ones. If the update fails, you can rollback: 'kubectl rollout undo deployment/hello-world'. This step demonstrates the orchestration power of AKS—zero-downtime deployments and elastic scaling.
Scenario 1: Event-Driven Image Processing
A media company needs to process user-uploaded images: resize, compress, and add watermarks. The workload is unpredictable—spikes after a marketing campaign, then quiet periods. Using ACI, they create a container that runs a Python script to process images. When a new image is uploaded to Azure Blob Storage, an Azure Function triggers ACI to launch a container with the image URL as an environment variable. The container processes the image, saves the result to another blob, and exits. The company pays only for the few seconds each container runs. This is cost-effective because no VMs are running idle. If they had used VMs, they'd need to keep them running 24/7 or implement complex autoscaling. With ACI, scaling is automatic and per-second billing matches the sporadic workload. Common mistake: forgetting to set the restart policy to 'Never' for batch jobs, causing the container to restart and reprocess the same image repeatedly, leading to unexpected costs.
Scenario 2: Microservices Architecture for E-Commerce
An online retailer migrates from a monolithic .NET application to microservices: product catalog, shopping cart, payment, and recommendation engine. They choose AKS for orchestration. Each microservice runs in its own set of pods, with deployments for resiliency. AKS handles rolling updates—when a new version of the payment service is deployed, pods are updated one by one, ensuring no downtime. The Horizontal Pod Autoscaler scales the catalog service during Black Friday traffic. The Cluster Autoscaler adds more nodes when pods cannot be scheduled due to resource constraints. They integrate Azure DevOps for CI/CD, pushing new container images to ACR, which triggers automated deployment. The cost is the worker VMs plus the load balancer. If they had used ACI for this, they'd lose orchestration features; each microservice would need manual scaling and networking setup. Common pitfall: misconfiguring resource requests and limits, leading to pod eviction or node overload.
Scenario 3: Hybrid Batch Processing with ACI and AKS
A financial services firm runs a Kubernetes cluster for its core trading platform (AKS). During month-end reporting, they need extra compute capacity for risk calculations. Instead of over-provisioning the AKS cluster, they enable virtual nodes (using ACI as the node provider). When the Cluster Autoscaler detects pending pods, it schedules them on ACI containers rather than new VMs. This provides burst capacity in seconds without provisioning new VMs. The ACI containers are ephemeral, so the firm doesn't pay for idle capacity. They configure pod priorities so that burst pods are preemptible if needed. This hybrid approach combines the orchestration of AKS with the instant scaling of ACI. Common mistake: not setting appropriate pod priority classes, causing critical pods to be evicted by burst pods.
Objective 2.2: Describe core Azure services – This includes understanding the purpose and use cases of ACI and AKS, not the internal workings of Kubernetes. The exam expects you to know:
ACI is for simple, single-container scenarios that need fast startup and per-second billing.
AKS is for orchestrating multiple containers, with automatic scaling, updates, and self-healing.
Both are container services, but ACI is serverless (no infrastructure management) while AKS requires managing node pools.
Common Wrong Answers and Why Candidates Choose Them
'ACI is for large-scale microservices deployments.' – Wrong. Candidates confuse ACI with AKS. ACI lacks orchestration features like load balancing, service discovery, and rolling updates. The correct answer: AKS is for large-scale microservices.
'AKS is easier to set up than ACI.' – Wrong. ACI is simpler because it requires no cluster creation or kubectl. AKS takes 5-10 minutes to provision and requires understanding of Kubernetes concepts.
'Containers are the same as virtual machines.' – Wrong. Containers share the host OS kernel, while VMs have their own OS. The exam tests this distinction. Candidates pick 'containers are lighter than VMs' as true, but sometimes the phrasing 'containers run on a hypervisor' is false.
'ACI requires you to manage the underlying VMs.' – Wrong. ACI is serverless; you do not see or manage VMs. Only AKS requires you to manage node VMs (though Azure manages the control plane).
Specific Terms and Values
ACI: 'container group,' 'restart policy' (Always, OnFailure, Never), 'per-second billing,' 'CPU up to 4 cores, memory up to 16 GB.'
AKS: 'node pool,' 'control plane (free),' 'kubectl,' 'pod,' 'deployment,' 'service,' 'Horizontal Pod Autoscaler,' 'Cluster Autoscaler.'
SLA: ACI offers 99.9% SLA for container groups with more than one container; AKS offers 99.95% SLA for the Kubernetes API server (control plane) when using availability zones.
Edge Cases and Tricky Distinctions
The exam may ask: 'Which service should you use to run a batch job that takes 30 seconds and runs once per hour?' Answer: ACI (serverless, per-second billing).
'Which service should you use to run a multi-tier web application with a frontend, backend, and database, with automatic scaling?' Answer: AKS.
'Which service requires you to patch the underlying OS?' Answer: AKS (you patch node VMs). ACI does not require OS patching.
'Can you run Windows containers in ACI?' Yes, ACI supports both Linux and Windows containers. AKS also supports Windows node pools.
Memory Trick
Think: 'I' in ACI stands for 'Instant' – quick, simple, single container. 'K' in AKS stands for 'Kubernetes' – complex orchestration for many containers. Alternatively: 'ACI = A Container Instance' (just one), 'AKS = A Kubernetes System' (many containers managed together).
Decision Tree for Eliminating Wrong Answers
Is the scenario about running a single container quickly without managing servers? → ACI.
Is it about orchestrating multiple containers with scaling and updates? → AKS.
Does the question mention 'serverless containers' or 'per-second billing'? → ACI.
Does it mention 'node pools,' 'kubectl,' or 'pods'? → AKS.
If the question asks about 'container orchestration,' always pick AKS.
ACI is a serverless container service for running a single container or a small group of containers with per-second billing.
AKS is a managed Kubernetes service for orchestrating multiple containers across a cluster of VMs.
ACI starts containers in seconds; AKS takes minutes to provision nodes.
ACI is ideal for event-driven, batch, or simple web apps; AKS is for production microservices with complex scaling and update requirements.
The control plane in AKS is free; you pay only for worker nodes, storage, and networking.
AKS supports automatic scaling via Horizontal Pod Autoscaler and Cluster Autoscaler.
ACI and AKS can be used together via virtual nodes in AKS, which use ACI for burst capacity.
These come up on the exam all the time. Here's how to tell them apart.
Azure Container Instances (ACI)
Serverless – no infrastructure to manage
Startup in seconds
Per-second billing
Best for single containers or simple batch jobs
Limited orchestration (container groups only)
Azure Kubernetes Service (AKS)
Managed Kubernetes – control plane is free, you manage nodes
Startup in minutes (nodes must provision)
Per-VM-hour billing (plus control plane free)
Best for multi-container microservices
Full orchestration – scaling, updates, self-healing
Mistake
ACI can orchestrate multiple containers across different hosts.
Correct
ACI only supports container groups, where all containers run on the same host and share the same lifecycle. For multi-host orchestration, you need AKS.
Mistake
AKS is a free service with no compute costs.
Correct
The control plane is free, but you pay for the worker node VMs, storage, and networking. The total cost can be significant for large clusters.
Mistake
Containers in ACI are always running and incur costs even when idle.
Correct
ACI charges per second of runtime. If the container exits (e.g., batch job completes), billing stops. You can also stop the container group manually.
Mistake
AKS requires you to manage Kubernetes master nodes.
Correct
AKS is a managed service; Azure manages the control plane (master nodes). You only manage the worker nodes.
Mistake
You can run containers directly on a VM without any container runtime.
Correct
Containers require a container runtime (e.g., Docker, containerd) installed on the host. ACI and AKS handle this for you.
ACI (Azure Container Instances) is a serverless container service that runs a single container or a small group of containers on the same host. It starts in seconds and bills per second. AKS (Azure Kubernetes Service) is a managed Kubernetes orchestration platform that runs multiple containers across a cluster of VMs. AKS provides automatic scaling, rolling updates, and self-healing but requires managing node VMs. Use ACI for simple, quick tasks; use AKS for complex, production-grade microservices.
Yes. AKS supports virtual nodes, which allow you to schedule pods on ACI instead of on worker VMs. This provides burst capacity for scaling quickly without provisioning new VMs. When the Cluster Autoscaler detects pending pods, it can schedule them on ACI containers. This hybrid approach combines the orchestration of AKS with the instant scaling of ACI. However, virtual nodes have limitations, such as not supporting all Kubernetes features (e.g., daemonsets, statefulsets).
Consider the complexity and scaling needs. If you have a simple, single-container application that runs occasionally or in response to events, choose ACI for its simplicity and per-second billing. If you have a multi-container application with microservices that need to scale automatically, handle rolling updates, and maintain high availability, choose AKS. Also, consider team expertise: AKS requires knowledge of Kubernetes, while ACI is straightforward.
ACI offers a 99.9% SLA for container groups that have more than one container. For single-container groups, there is no SLA. AKS offers a 99.95% SLA for the Kubernetes API server (control plane) when deployed in multiple availability zones. The worker nodes are covered by the VM SLA (typically 99.9% for single VM, 99.95% for availability sets, 99.99% for availability zones).
In ACI, you do not manage the underlying OS; Azure handles patching. In AKS, you are responsible for patching the worker node VMs. However, Azure provides node image updates and you can use cluster upgrades to apply Kubernetes version updates. AKS also offers automatic node image upgrades in preview. The control plane is patched automatically by Azure.
Yes. ACI supports both Linux and Windows containers. When creating a container group, you specify the OS type. AKS supports Windows node pools, allowing you to run Windows containers alongside Linux containers. However, Windows containers have some limitations compared to Linux (e.g., larger image sizes, fewer base images).
A container group is a collection of containers that are scheduled on the same host machine. All containers in a group share the same lifecycle, network namespace, IP address, and storage volumes. This is useful for sidecar patterns (e.g., a web server and a logging agent). Container groups are the top-level resource in ACI; you cannot have nested groups. They are analogous to a pod in Kubernetes.
You've just covered Azure Container Instances and AKS — now see how well it sticks with free AZ-900 practice questions. Full explanations included, no account needed.
Done with this chapter?