Container Solutions: AKS, ACI & Container Apps
Azure Kubernetes Service, Azure Container Instances, and Azure Container Apps — choose the right container platform based on orchestration needs, scale, and management overhead.
Choosing a container platform
Three options, three levels of control:
AKS: Full Kubernetes — you control everything about the cluster. Like owning a fleet of trucks with a dispatch centre.
Container Apps: Serverless containers — Azure manages the cluster. Like using a delivery service that handles logistics for you.
ACI: Run a single container quickly — no cluster needed. Like calling a courier for one package.
Container platform comparison
| Factor | AKS | Azure Container Apps | Azure Container Instances |
|---|---|---|---|
| Orchestration | Full Kubernetes (you manage) | Managed (serverless Kubernetes) | None (single container/group) |
| Scaling | HPA, VPA, cluster autoscaler, KEDA | Built-in KEDA + HTTP scaling | Manual (increase count) |
| Networking | Full control (CNI, service mesh, ingress) | Managed ingress, VNet integration | VNet integration, public IP |
| Min running cost | Node pool VMs (always on) | Zero (scale to 0 with Consumption plan) | Per-second billing (no min when stopped) |
| GPU support | Yes | No | Yes |
| Windows containers | Yes (Windows node pools) | No — Linux containers only | Yes |
| Kubernetes knowledge needed | High — kubectl, YAML manifests, Helm | Low — simplified YAML or CLI | None |
| Best for | Complex microservices, custom K8s features, ML workloads | Microservices with simpler ops, event-driven containers | Burst workloads, CI/CD runners, sidecar tasks |
🚀 Marcus’s decision: NovaSaaS uses Container Apps for their microservices:
- Scales to zero during off-hours (cost savings)
- Built-in Dapr for service-to-service communication
- KEDA scales based on queue depth (event-driven)
- No Kubernetes expertise needed — Marcus’s team focuses on code, not cluster ops
🏗️ Priya’s decision: GlobalTech’s data science team uses AKS because:
- GPU node pools for ML model training
- Custom networking (service mesh for inter-service security)
- Helm charts and GitOps deployment (team has deep K8s expertise)
- Need fine-grained resource quotas and namespaces per team
Exam tip: Container Apps is the growing default answer
Microsoft is increasingly positioning Container Apps as the default for microservices. If the scenario doesn’t mention specific Kubernetes features (service mesh, custom CRDs, GPU, advanced scheduling), Container Apps is likely the correct answer. Choose AKS only when the scenario needs full Kubernetes control or features Container Apps doesn’t support.
ACI as a burst target for AKS
AKS can use ACI as a virtual node for burst scaling — called the virtual kubelet pattern:
- Normal load: pods run on AKS node pool VMs
- Burst: overflow pods scheduled to ACI (near-instant, no node provisioning)
- Cost: pay per-second for ACI pods, no pre-provisioned VMs for burst capacity
Knowledge check
🚀 NovaSaaS's development team wants to run 30 microservices that scale based on HTTP requests and message queue depth. They want to scale to zero during off-peak hours. The team has no Kubernetes experience. Which platform should Marcus recommend?
🏛️ David's government client wants to run containers on AKS with these requirements: pods must have direct VNet IPs for firewall rules, container images must be scanned before deployment, and only approved registries are allowed. Which combination should David recommend?
Next up: When you don’t even need containers — Serverless & Batch Processing.