Azure Container Apps vs AKS vs ACI

Containers provide lightweight, portable application packaging. Azure offers three services to run containers, each at a different level of abstraction and control: ACI, AKS, and ACA. The exam tests your ability to choose the right service based on requirements like orchestration needs, scaling, networking, and operational overhead.

ACI is the simplest way to run a container in Azure without managing virtual machines or orchestration. It is a PaaS offering that launches a container directly on Azure infrastructure. Under the hood, ACI uses a hypervisor-level isolation technology called "Hyper-V containers" to ensure each container instance runs in its own security boundary. You can launch a container with a single command:

az container create --resource-group myRG --name mycontainer --image mcr.microsoft.com/azuredocs/aci-helloworld --dns-name-label mycontainer --ports 80

ACI supports both Linux and Windows containers. Key attributes: - Pricing: Per-second billing while the container is running. - Scaling: Manual scaling only — you cannot auto-scale. You can create multiple container groups, but not automatically. - Networking: Each container gets a public IP address and FQDN. You can also deploy into a virtual network (VNet) for private communication. - Storage: Supports Azure Files mounts for persistent storage. - Limits: Single container group can have up to 60 containers on Linux, 4 on Windows. CPU and memory limits per container group: up to 4 vCPUs and 16 GB memory (Linux) or 4 vCPUs and 16 GB (Windows). - Use cases: Simple batch jobs, build tasks, small web apps, or testing.

ACI is not suitable for multi-container microservices that need service discovery, load balancing, or auto-scaling.

AKS is a managed Kubernetes service. Kubernetes is an open-source container orchestration platform that automates deployment, scaling, and management of containerized applications. AKS simplifies cluster creation and management by providing a managed control plane (the Kubernetes master components) for free — you only pay for the worker nodes (VMs).

Under the hood, AKS provisions a control plane (API server, etcd, scheduler, controller manager) in a Microsoft-managed subscription, and worker nodes in your subscription. You define desired state in YAML manifests (Deployments, Services, Ingress, etc.). The Kubernetes scheduler places pods onto nodes based on resource requests and constraints.

Key features: - Auto-scaling: Cluster autoscaler adds/removes nodes; Horizontal Pod Autoscaler (HPA) scales pods based on CPU/memory or custom metrics. - Networking: Supports Azure CNI (advanced networking) where each pod gets an IP from the VNet, or kubenet (basic) with private IPs and NAT. Azure Load Balancer integrates natively for external traffic. - Storage: Persistent volumes via Azure Disk or Azure Files with StorageClass definitions. - Security: Azure AD integration, RBAC, network policies via Calico or Azure Network Policy, and Azure Policy for Kubernetes. - Upgrades: Managed Kubernetes version upgrades for control plane and node pools. - Monitoring: Azure Monitor for containers, Container Insights.

Typical AKS cluster creation:

az aks create --resource-group myRG --name myAKSCluster --node-count 3 --enable-addons monitoring --generate-ssh-keys

AKS is the right choice when you need full control over orchestration, custom networking policies, or complex multi-container applications. However, it requires Kubernetes expertise to manage.

Azure Container Apps is a serverless container platform that abstracts Kubernetes complexities. It runs on top of a hidden AKS cluster, but you never interact with Kubernetes directly. Instead, you define container apps, revisions, ingress, and scaling rules via ARM templates, Bicep, or the Azure CLI.

Under the hood, ACA uses the open-source Dapr (Distributed Application Runtime) and KEDA (Kubernetes Event-Driven Autoscaling). Dapr provides building blocks for microservices: service-to-service invocation, state management, pub/sub, and bindings. KEDA enables event-driven scaling based on queue length, HTTP traffic, cron schedules, etc.

Key attributes: - Scaling: Automatic scaling to zero when idle. You define scaling rules (e.g., based on HTTP concurrency, Azure Service Bus queue length, or custom KEDA scalers). - Networking: Each container app gets a fully qualified domain name (FQDN) with managed TLS termination. You can enable ingress with external or internal traffic. VNet integration is supported for private networking. - Revisions: Supports multiple revisions of a container app for blue-green deployments and traffic splitting. - Environment: Container apps run in a Container Apps Environment, which is a secure boundary around a set of apps. The environment is backed by a virtual network. - Limits: Maximum 30 apps per environment. Each app can have up to 4 GB memory and 4 vCPUs. Minimum 0.25 vCPU and 0.5 GB memory. - Pricing: Consumption plan (pay per second of compute, plus fixed cost per environment) or dedicated plan (reserved instances).

Example creation:

az containerapp create --resource-group myRG --name myapp --environment myenv --image myregistry.azurecr.io/myapp:v1 --target-port 80 --ingress external

ACA is ideal for microservices that need built-in scaling, Dapr capabilities, and simpler management than AKS. It is not suitable for workloads requiring direct Kubernetes API access or custom node configurations.

The AZ-104 exam will present scenarios with constraints like: - "You need to run a container that processes a batch job and then stops." → ACI. - "You need a fully managed Kubernetes cluster with granular control over networking policies." → AKS. - "You need a serverless platform for microservices with automatic scaling and Dapr integration." → ACA. - "You need to run a containerized app that scales to zero when not in use." → ACA (or ACI if you stop manually, but ACA does it automatically). - "You need to use Kubernetes-native tools like Helm or Istio." → AKS.

All three services integrate with Azure Container Registry (ACR) for storing container images. AKS and ACA can use managed identities for authentication to ACR without secrets. ACI can pull from ACR using image registry credentials.

For monitoring, AKS uses Container Insights (part of Azure Monitor), while ACA has built-in monitoring with Log Analytics. ACI provides basic logs via az container logs.

Networking: ACI supports VNet integration but is limited; AKS offers full control with Azure CNI; ACA provides managed ingress with automatic TLS and supports VNet integration via the environment.

Candidates often confuse "serverless" with "no scaling limits." ACA scales to zero, but has resource limits per app. AKS can scale to zero nodes using virtual nodes (ACI), but that's a separate feature. ACI does not auto-scale — you must manually create instances.

A financial services company needs to process end-of-day risk calculations for thousands of portfolios. Each portfolio is independent and can be processed in a container. They choose ACI because the workload is batch-oriented and runs for 30 minutes each night. They deploy 200 container groups using an Azure DevOps pipeline, each pulling a custom image from ACR. They use Azure Files to share output data. The key consideration is cost: ACI's per-second billing is ideal since containers run only for the calculation duration. They set up a logic app to trigger the containers and collect results. A common misconfiguration is not cleaning up containers after completion, leading to unnecessary costs. They implement a retry logic for failed containers using Azure Functions.

A retail company modernizes its e-commerce platform into microservices. They choose ACA because it provides built-in Dapr support for service-to-service calls and pub/sub, reducing development effort. Each microservice runs as a container app with HTTP scaling rules. They use KEDA to scale based on Azure Service Bus queue length for order processing. The platform handles Black Friday traffic spikes by scaling to hundreds of replicas automatically. They split traffic between blue-green revisions for zero-downtime deployments. The challenge is debugging Dapr configuration; they use Azure Monitor for traces. Misconfiguring scaling rules (e.g., too low concurrency threshold) can cause unnecessary scaling events, increasing costs.

A healthcare SaaS provider runs a multi-tenant application on AKS. They need fine-grained network policies to isolate tenant traffic. They use Azure CNI for pod-level VNet IPs and Calico network policies. They deploy Istio for mTLS and traffic management. The cluster has 50 nodes with 500 pods. They use Azure AD integration for RBAC and Azure Policy for compliance. The main pain point is managing node upgrades: they use multiple node pools and cordon/drain nodes during updates. A common mistake is not setting resource requests/limits, leading to noisy neighbor issues. They use Azure Cost Management to track costs per namespace.