This chapter covers Azure Container Instances (ACI) and Azure Kubernetes Service (AKS) basics, two core compute options for running containers on Azure. For the AZ-104 exam, this topic falls under Objective 3.3: Implement and manage containerization solutions. Expect 5-10% of exam questions to touch on container services, testing your ability to choose between ACI and AKS, configure container groups, deploy clusters, and manage basic Kubernetes workloads. Understanding when to use each service and how to configure them is critical.
Jump to a section
Azure Container Instances (ACI) is like a hotel that rents out individual rooms on demand. You walk in, pay for a room, stay as long as you need, and leave. The hotel staff handles cleaning, linens, and maintenance. You don't care about the hotel's plumbing or electrical systems—you just need a room. In contrast, Azure Kubernetes Service (AKS) is like a large apartment complex with a property management team. You rent an entire building (cluster) and have multiple apartments (pods) that you manage yourself. The management team handles the building's infrastructure—elevators, security, parking—but you are responsible for furnishing each apartment, moving tenants in and out, and ensuring the building's common areas (like load balancing and networking) work correctly. With AKS, you have flexibility to customize each apartment, but you also need to know how to use the building's systems (Kubernetes API, kubectl) to manage your tenants. ACI is simpler—just run a container—while AKS gives you control and scalability for complex applications.
What Are Azure Container Instances and AKS?
Azure Container Instances (ACI) is a PaaS offering that lets you run a single container or a small group of containers directly in Azure without managing underlying virtual machines or orchestrators. It is designed for simple, fast, and isolated container execution. ACI is ideal for burst tasks, batch jobs, event-driven processing, and simple microservices where you want to avoid the complexity of cluster management.
Azure Kubernetes Service (AKS) is a managed Kubernetes service that simplifies deploying, managing, and scaling containerized applications using Kubernetes. AKS provides a fully managed control plane (API server, etcd, scheduler) and lets you manage worker nodes as virtual machine scale sets. It is designed for production-grade, multi-container applications requiring orchestration, service discovery, auto-scaling, rolling updates, and self-healing.
How They Work Internally
ACI: When you create a container instance, Azure provisions a hypervisor-isolated container directly on Azure infrastructure. The container runs in a secure, isolated environment with its own IP address (if using default networking) or within a virtual network. ACI supports both Linux and Windows containers. Each container instance is a single container or a container group (multiple containers sharing the same lifecycle, network, and storage). The container group is scheduled on a single host machine. You can specify CPU, memory, GPU, and ephemeral storage. ACI automatically restarts containers on failure if the restart policy is set to Always or OnFailure.
AKS: AKS deploys a Kubernetes cluster with a managed control plane. The control plane components (API server, etcd, scheduler, controller manager) are managed by Azure and are highly available by default. Worker nodes are VMs running in a scale set, which can be configured with node pools. You interact with the cluster using kubectl. When you deploy a workload (e.g., a Deployment), the Kubernetes scheduler places pods onto worker nodes. Each pod gets an IP from the cluster's virtual network (Azure CNI or kubenet). AKS integrates with Azure Active Directory for authentication, Azure Container Registry for image storage, and Azure Monitor for logging and monitoring.
Key Components, Values, Defaults, and Timers
ACI: - Container group: The top-level resource. All containers in a group share the same host, network namespace (same IP, port space), and lifecycle. - Restart policy: Always, OnFailure, Never. Default is Always. - OS type: Linux or Windows. Default is Linux. - CPU and memory: Minimum 1 vCPU, 1 GB RAM. Maximum 4 vCPU, 16 GB RAM for Linux; 4 vCPU, 16 GB for Windows (varies by region). - GPU: Available in specific regions (e.g., West US 2). Supports K80, P100, V100. - Networking: Default is public IP with a FQDN. Can be deployed into a virtual network (requires subnet delegation). - Storage: Azure Files shares can be mounted as volumes. Supports emptyDir, gitRepo, secret, configMap. - Liveness/readiness probes: Supported but not required. - Billing: Per-second billing, minimum 1 minute.
AKS: - Cluster: Consists of a control plane and node pools. Control plane is free; you pay for worker nodes. - Node pools: One or more VM scale sets. Default node pool is created at cluster creation. Can have system and user node pools. - Node size: Default Standard_DS2_v2 (2 vCPU, 7 GB RAM). Customizable. - Scaling: Manual or cluster autoscaler (scales node pools based on unschedulable pods). - Kubernetes version: Supported versions are listed in the AKS release notes. Upgrades are managed. - Networking: Two modes – kubenet (default, uses internal IPs and Azure load balancer for outbound) and Azure CNI (each pod gets a VNet IP, better performance, but requires IP planning). - Storage: Persistent volumes via Azure Disk (ReadWriteOnce) or Azure Files (ReadWriteMany). - Authentication: AKS integrates with Azure AD for user authentication. Kubernetes RBAC is enabled by default. - Monitoring: Azure Monitor for containers (Container Insights) is optional but recommended. - Service mesh: Istio or Open Service Mesh can be installed.
Configuration and Verification Commands
ACI: Create a container instance:
az container create --resource-group myRG --name mycontainer --image mcr.microsoft.com/azuredocs/aci-helloworld --ports 80 --dns-name-label mycontainer --location eastusVerify:
az container show --resource-group myRG --name mycontainer --query instanceView.stateList logs:
az container logs --resource-group myRG --name mycontainerAttach to running container:
az container attach --resource-group myRG --name mycontainerAKS: Create an AKS cluster:
az aks create --resource-group myRG --name myAKSCluster --node-count 3 --enable-addons monitoring --generate-ssh-keysGet credentials:
az aks get-credentials --resource-group myRG --name myAKSClusterVerify nodes:
kubectl get nodesDeploy an application (using a YAML file or imperative):
kubectl create deployment myapp --image=nginx --replicas=3
kubectl expose deployment myapp --port=80 --type=LoadBalancerCheck pods:
kubectl get podsHow It Interacts with Related Technologies
Azure Container Registry (ACR): Both ACI and AKS use ACR as a private container registry. ACI can pull images from ACR using managed identity or admin credentials. AKS can integrate with ACR via role assignment (AcrPull role) for seamless authentication.
Azure Virtual Network: ACI can be deployed into a VNet for private IP communication. AKS uses VNet for pod networking (Azure CNI) and for communication with other Azure services.
Azure Monitor: Container Insights for AKS provides metrics, logs, and alerts. ACI metrics (CPU, memory, network) are available via Azure Monitor.
Azure AD: AKS supports Azure AD integration for user authentication. ACI does not have direct Azure AD integration; authentication is via container settings.
Azure Policy: AKS can be governed by Azure Policy for Kubernetes (e.g., enforcing pod security policies). ACI is not directly controlled by Azure Policy.
Azure DevOps: Both can be used in CI/CD pipelines. ACI is often used for build agents or test containers; AKS for deploying production workloads.
Choose between ACI and AKS
Evaluate your application requirements. Use ACI for simple, stateless containers that need to run quickly without orchestration. Use AKS for multi-container applications requiring scaling, service discovery, rolling updates, and self-healing. ACI is best for batch jobs, event-driven tasks, and development/testing. AKS is best for production microservices and complex workloads.
Create container instance or cluster
For ACI, use the Azure portal, CLI, or ARM template to create a container group. Specify the image, resources, ports, and restart policy. For AKS, use the portal or CLI to create a cluster, specifying node count, VM size, networking mode, and add-ons like monitoring. The control plane is automatically provisioned and managed.
Configure networking
For ACI, decide whether to use a public IP or deploy into a VNet. If deploying into a VNet, delegate a subnet to Microsoft.ContainerInstance/containerGroups. For AKS, choose between kubenet (default) and Azure CNI. Kubenet is simpler but each pod gets an internal IP; Azure CNI gives each pod a VNet IP, enabling direct connectivity to other VNet resources.
Deploy and manage containers
For ACI, use az container create or deploy via ARM. Monitor logs with az container logs. For AKS, use kubectl to create deployments, services, and other Kubernetes objects. Use YAML manifests for declarative management. Expose applications via LoadBalancer or Ingress. Use horizontal pod autoscaler (HPA) for scaling based on CPU/memory.
Monitor and troubleshoot
For ACI, check container state with az container show, view logs, and attach to the container for interactive troubleshooting. For AKS, use kubectl logs, describe, and exec. Enable Container Insights for metrics and logs. Use Azure Monitor alerts for node and pod failures. Analyze performance with kubectl top nodes and pods.
Enterprise Scenario 1: Batch Processing with ACI
A financial services company needs to run thousands of risk calculations daily. Each calculation is a stateless, CPU-intensive task that runs for 5-10 minutes. They use ACI with a container group per job, specifying CPU and memory requirements. They deploy containers into a VNet to access a private database. They use Azure Logic Apps to trigger container creation on a schedule. The key consideration is cost: per-second billing means they only pay for runtime. Misconfiguration: if they set restart policy to Always, failed jobs would restart indefinitely, causing unexpected costs. They set restart policy to OnFailure to retry once, then alert on failure.
Enterprise Scenario 2: Microservices on AKS
An e-commerce platform runs multiple microservices (catalog, cart, checkout, payment) on AKS. They use a multi-node pool cluster: system node pool for critical components, user node pools for stateless services. They use Azure CNI for pod-to-pod communication and an Application Gateway Ingress Controller for HTTP routing. They enable cluster autoscaler to add nodes during peak shopping hours. They use Azure DevOps for CI/CD, deploying via Helm charts. Common issue: forgetting to set resource requests/limits, causing pods to be evicted during high load. They enforce resource quotas per namespace.
Enterprise Scenario 3: Event-Driven Containers with ACI and Azure Functions
A media company processes uploaded videos. When a video is uploaded to Blob Storage, an Azure Function triggers an ACI container that runs FFmpeg to transcode the video. The container mounts the blob as an Azure Files share for input and output. ACI is chosen because it can run a custom Linux container with FFmpeg installed, and it scales out per event. Key consideration: cold start time (a few seconds) is acceptable for this workload. Misconfiguration: if the container group does not have enough ephemeral storage, large videos fail. They set the --ephemeral-storage parameter to 100 GB.
The AZ-104 exam tests your ability to choose between ACI and AKS for given scenarios, configure basic deployments, and understand networking and storage integrations. Specific objectives: 3.3.1 Implement and manage container images (ACR), 3.3.2 Implement and manage Azure Container Instances, 3.3.3 Implement and manage Azure Kubernetes Service.
Common wrong answers: 1. 'ACI supports auto-scaling based on load.' – ACI does not auto-scale; you must create new instances manually or via triggers. AKS has HPA and cluster autoscaler. 2. 'AKS requires you to manage the control plane.' – AKS manages the control plane; you manage worker nodes. 3. 'ACI can be used for long-running stateful applications.' – ACI is ephemeral; state should be externalized (e.g., Azure Files). For stateful apps, use AKS with persistent volumes. 4. 'Kubenet provides better performance than Azure CNI.' – Azure CNI provides better performance because pods get VNet IPs directly; kubenet uses NAT.
Key numbers and terms:
ACI default restart policy: Always
ACI minimum billing: 1 minute
AKS default node size: Standard_DS2_v2
AKS networking modes: kubenet (default) and Azure CNI
AKS node scaling: manual or cluster autoscaler
ACR integration: AcrPull role
Edge cases:
ACI with GPU requires specific regions and quota.
AKS with Azure CNI requires sufficient IP space in the subnet (each pod gets an IP).
Windows containers on AKS have limitations (e.g., no HPA for Windows nodes).
Elimination strategy: If the scenario mentions 'simple, single container', 'batch job', or 'no orchestration', choose ACI. If it mentions 'microservices', 'scaling', 'rolling updates', 'service discovery', choose AKS. Always check for networking requirements (VNet vs public) and state persistence.
ACI is for simple, stateless containers without orchestration; AKS is for complex, multi-container apps requiring orchestration.
ACI default restart policy is Always; set to OnFailure or Never for batch jobs.
AKS control plane is managed by Azure; you manage worker nodes and workloads.
Kubenet is simpler but less performant than Azure CNI; Azure CNI gives each pod a VNet IP.
AKS integrates with ACR using AcrPull role; ACI can use admin credentials or managed identity.
ACI minimum billing is 1 minute; per-second billing after that.
AKS supports Windows containers only with a dedicated Windows node pool.
ACI can be deployed into a VNet for private IP; requires subnet delegation.
These come up on the exam all the time. Here's how to tell them apart.
Azure Container Instances (ACI)
No orchestration – run a single container or small group
No cluster management – fully managed by Azure
Per-second billing, minimum 1 minute
Limited scaling – must create new instances manually
Best for simple, stateless, short-lived tasks
Azure Kubernetes Service (AKS)
Full Kubernetes orchestration – deployments, services, auto-scaling
Managed control plane, but you manage worker nodes
Pay for worker nodes (VMs) – no per-second billing
Built-in HPA and cluster autoscaler
Best for complex, multi-container, production workloads
Mistake
ACI supports auto-scaling based on CPU or memory load.
Correct
ACI does not have built-in auto-scaling. You must use external triggers (e.g., Azure Functions, Logic Apps) to create new container instances. AKS supports horizontal pod autoscaling (HPA) and cluster autoscaler.
Mistake
AKS requires you to manage the Kubernetes control plane.
Correct
AKS is a managed Kubernetes service. Microsoft manages the control plane components (API server, etcd, scheduler, controller manager). You only manage worker nodes and workloads.
Mistake
ACI can run stateful applications with built-in persistent storage.
Correct
ACI containers are ephemeral. For persistent data, you must mount external storage like Azure Files. The container itself does not retain state after restart. AKS supports persistent volumes (Azure Disk, Azure Files).
Mistake
Kubenet is faster than Azure CNI because it uses fewer IP addresses.
Correct
Azure CNI provides better performance because pods get direct VNet IPs, avoiding NAT. Kubenet uses NAT for outbound traffic and is simpler for small clusters. Azure CNI requires more IP addresses but is recommended for production.
Mistake
You can deploy Windows containers on any AKS cluster.
Correct
Windows containers require a node pool with a Windows OS SKU. Not all Kubernetes versions support Windows. You must add a Windows node pool after creating the cluster.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Use ACI when you need to run a single container or a small group of containers quickly without managing orchestration. Common use cases include batch jobs, event-driven processing, and simple microservices where you don't need scaling, service discovery, or rolling updates. AKS is overkill for these scenarios. If you need Kubernetes features like auto-scaling, load balancing, and self-healing, use AKS.
Yes, ACI supports restart policies: Always (default), OnFailure, and Never. If set to Always, the container restarts automatically after it exits, regardless of exit code. OnFailure restarts only if the container exits with a non-zero exit code. Never means the container runs once and stops. For batch jobs, use OnFailure to retry on failure.
To deploy ACI into a virtual network, you must create a subnet and delegate it to Microsoft.ContainerInstance/containerGroups. Then, when creating the container group, specify the subnet ID. The container will get a private IP from that subnet. This enables communication with other VNet resources without a public IP.
Kubenet is the default networking mode. Pods get internal IPs from a private address space, and traffic is NATed to the node's IP for outbound communication. Azure CNI gives each pod a VNet IP, enabling direct connectivity to other VNet resources. Azure CNI is faster but requires more IP addresses. Use Azure CNI for production and when you need direct pod-to-pod communication.
ACI does not support auto-scaling. To scale, you must create multiple container instances manually or use an external trigger (e.g., Azure Functions, Logic Apps, or Azure Batch). You can also use a container group with multiple containers, but they share the same lifecycle. For dynamic scaling, use AKS.
Yes, AKS integrates with Azure AD for user authentication. You can enable Azure AD integration when creating the cluster or later. Users then authenticate using their Azure AD credentials to access the Kubernetes API. Kubernetes RBAC is used for authorization. ACI does not support Azure AD authentication directly.
The minimum configuration is 1 vCPU and 1 GB of memory. You must specify at least a container image. Other parameters like ports, restart policy, and environment variables are optional. If no restart policy is set, it defaults to Always.
You've just covered Azure Container Instances and AKS Basics — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?