When to Use What
Azure offers multiple compute options for containers. This lesson builds a complete decision matrix across ACI, AKS, App Service (containers), and Azure Functions — so you always recommend the right service.
The Compute Decision Tree
Short-lived?
No container required?
Long-running service?
Legacy app?
Full Comparison Matrix
| Feature | Azure Functions | App Service | ACI | AKS | VM/VMSS |
|---|---|---|---|---|---|
| Model | Serverless | PaaS | Container | Kubernetes | IaaS |
| Startup | Cold start (ms-sec) | Seconds | Seconds | Minutes (cluster) | Minutes |
| OS management | None | None | None | Partial (nodes) | Full |
| Scaling | Auto (to 0) | Auto (plan-based) | Manual | HPA + KEDA | VMSS autoscale |
| Persistence | Stateless | Stateless/Stateful | Ephemeral | PVC support | Full disk |
| Networking | VNet (Premium) | VNet integration | VNet optional | Full CNI | Full |
| Cost model | Per execution | Per plan tier | Per second | Node VMs + mgmt | Per VM hour |
| Complexity | Low | Low | Low | High | High |
| Best for | Events, triggers | Web apps, APIs | Batch, CI jobs | Microservices | Legacy, OS-control |
Containers: ACI vs AKS vs App Service (Container)
All three can run Docker containers. The difference is operational complexity and capability:
Use ACI when:
- The container runs for minutes to hours (batch, CI agent, ETL).
- No orchestration needed — just "run this image, wait for exit".
- You want the simplest possible container execution.
Use App Service (Container) when:
- You have a single containerized web app or API.
- You want deployment slots, CI/CD integration, and PaaS simplicity with your own image.
- Low traffic, predictable scale — not a microservices mesh.
Use AKS when:
- You have multiple microservices that need orchestration (service discovery, load balancing, rolling updates).
- You need advanced networking (Istio service mesh, Ingress controllers).
- You need persistent volumes (StatefulSets, databases in containers).
- Your team already knows Kubernetes.
Don't start with AKS because of hype. AKS is powerful but carries significant operational complexity. For most teams with under 10 services, App Service handles containerized workloads with far less effort. Reach for AKS when the team is Kubernetes-proficient and the workload genuinely needs its capabilities.
Real-world Combinations
Production architectures mix multiple services based on the work each component does:
| Scenario | Frontend | API | Background Work | Data |
|---|---|---|---|---|
| Startup web app | Static Website (Blob) | App Service | Functions | Azure SQL |
| Enterprise microservices | CDN + Blob | AKS | Functions / ACI | Cosmos DB + SQL MI |
| Data pipeline | N/A | Functions | ACI batch jobs | Blob + Azure SQL |
| Legacy migration | VM (IIS) | VM | VMSS | SQL MI |
Going Deeper on AKS
AKS is covered in full detail — cluster creation, networking, RBAC, CI/CD integration, and monitoring — in the dedicated AKS module. This lesson gives you the decision framework; the AKS module covers operational depth.
Interview Questions
Beginner
Azure Container Instances (ACI) — one CLI command, no cluster to manage. Runs the container and exits.
Scenario-based
API → App Service (managed PaaS, auto-scale, slots for deployments). Image processor → Azure Functions with Blob trigger (event-driven, serverless). Report generator → Azure Function with Timer trigger or ACI batch job (runs nightly, exits).
When you have 5+ services needing service mesh, Kubernetes-native config management, stateful workloads, team has k8s expertise, and you need fine-grained auto-scaling via KEDA.
Summary
Azure Functions for events, App Service for web apps, ACI for short container jobs, AKS for microservices at scale, VMs for full OS control. Most real-world architectures combine several of these. Start with the simplest option that meets the requirement — complexity can always be added, but rarely removed easily.