Azure Hosting: App Service vs Container Apps vs AKS
Azure gives you at least four credible places to run a web application or an API, and the marketing copy for all of them says roughly the same thing: managed, scalable, production-ready. That's not much help when you're the one who has to pick. App Service, Azure Container Instances (ACI), Azure Container Apps (ACA), and Azure Kubernetes Service (AKS) are genuinely different products with different failure modes, different cost shapes and, most importantly, different amounts of platform you're signing up to operate. This note is about making that choice deliberately rather than by habit, and about which parts of the decision are cheap to change later and which aren't.
How much of the platform you want to own
Almost every meaningful difference between these four services falls out of one variable: where the boundary sits between what Azure operates and what you operate.
App Service is the most opinionated. You bring code (or a single container image) and Azure handles the operating system, patching, load balancing, and TLS. That's a genuinely good trade for a conventional web app, and it's why App Service remains the fastest path from repository to production URL in Azure. The cost is that you get the platform's opinions whether or not they suit you: its runtimes, its networking model, its scaling unit.
AKS sits at the other end. You get real Kubernetes, which means you can run anything the ecosystem can run — custom ingress controllers, service meshes, operators, sidecars, workloads that expect to manage their own clustering. You also inherit the operational surface that comes with it. Microsoft manages the control plane; you manage the nodes, the upgrades, the network policy, and everything you install into the cluster.
Container Apps and ACI fill the middle. Container Apps offering microservice-shaped features — revisions, ingress, event-driven scaling, Dapr — without a cluster to run. ACI is deliberately the simplest thing that runs a container: no orchestrator, no scaling, just a container (or a small group of them) with an IP address.
A useful way to hold this is that you're not choosing a hosting service so much as choosing how much Kubernetes you want, from none at all to all of it.
Containers versus virtual machines
Before choosing between container services, it's worth being precise about what a container actually buys you over a VM, because the isolation difference in particular has security consequences that get glossed over.
| Compare | Containers | Virtual machines |
|---|---|---|
| Isolation | Lightweight isolation from the host and other containers, but not as strong a security boundary as a virtual machine | Complete isolation from the host OS and other VMs. Matters when a strong security boundary is critical. For example hosting apps from competing companies on the same server or cluster |
| Operating system | Runs the user-mode portion of an OS, tailored to just the services the app needs. Uses fewer system resources | Runs a complete OS including the kernel, requiring more CPU, memory, and storage |
| Deployment | Individual containers via Docker from the command line; multiple containers via an orchestrator such as AKS | Individual VMs via Windows Admin Center or Hyper-V Manager; multiple VMs via PowerShell or System Center Virtual Machine Manager |
| Persistent storage | Azure Disks for local storage on a single node, or Azure Files (SMB shares) for storage shared across multiple nodes | A virtual hard disk (VHD) for a single machine, or an SMB file share for storage shared across servers |
| Fault tolerance | If a cluster node fails, the orchestrator rapidly recreates the containers on another node | VMs fail over to another server in a cluster, where the VM's OS restarts on the new server |
The isolation row is the one to internalise. Containers share a kernel; that's what makes them cheap, and it's also why a hard multi-tenancy boundary — different customers, different trust domains, regulatory separation — is a case for VMs or at minimum separate clusters, not for packing more containers onto shared nodes. For the VM side of this comparison in more depth, see the companion notes on Virtual Machines and Deploying Virtual Machines.
Comparing the hosting models
| Feature | App Service |
Container Instances (ACI) |
Container Apps (ACA) |
AKS |
|---|---|---|---|---|
| Service type | PaaS, optimised for web apps and APIs | Serverless single-container hosting, no orchestrator | Serverless container platform for microservices, built on AKS | Managed Kubernetes |
| Who manages what | Azure manages the OS and infrastructure entirely | Azure manages everything; you get correspondingly little control | Azure manages the cluster and orchestration, hidden from you | Microsoft manages the control plane; you manage the nodes, upgrades, and add-ons |
| Deployment unit | Code in a supported runtime, or a single container image | A container, or a container group scheduled on one host | Container images with revisions | Container images via Kubernetes manifests or Helm |
| Architecture fit | Traditional web apps and simple APIs | Short-lived tasks, build jobs, burst capacity | Microservices, event-driven and serverless workloads | Complex, long-running applications needing full Kubernetes |
| Scaling | Scales the plan — and so every app in it — by instance count. Does not scale to zero | No built-in scaling at all. Can pair with AKS for burst | HTTP-based and event-driven autoscaling; scales to zero | Horizontal pod autoscaling and cluster autoscaling; scale-to-zero via KEDA |
| OS support | Linux and Windows (mixed OS needs separate plans) | Linux and Windows | Linux only (linux/amd64) |
Linux and Windows |
| Control available | The platform's runtimes and capabilities only | Minimal; specs are immutable after deployment | Any image and runtime, plus sidecars and Dapr — but no cluster access | Full Kubernetes API: operators, CRDs, network policy, service mesh |
| Pricing model | Reserved instances — a largely fixed cost | Per-second billing, only while the container runs | Consumption-based on vCPU and memory, dropping to nothing at zero | Pay for the node VMs; the control plane is free |
The scaling and pricing rows are the ones that decide real budgets. An App Service plan bills for reserved compute whether or not traffic arrives, so you pay for at least one instance during idle periods. Container Apps can scale to zero, which makes it substantially cheaper for spiky or low-traffic workloads — and substantially more prone to cold starts, which is the trade the table doesn't show.
The OS row is worth acting on early, because it eliminates options rather than ranking them. A Windows container rules out Container Apps entirely, leaving ACI or AKS — or Web App for Containers, which supports Windows, though mixed-OS workloads need separate Windows and Linux App Service plans.
Where each one actually fits
App Service is the right default for traditional, often monolithic, web applications and APIs that want a quick path to production with built-in TLS, authentication, and deployment slots.
Container Apps or AKS suit modern applications built as microservices, background processing, or event-driven workloads. Cases needing granular scaling and the advanced networking that Dapr or a service mesh provides.
ACI is the lightweight option for running a single container or a small group for short-lived work — batch jobs, build agents, task automation — without the overhead of an orchestrator.
I'd add a caveat to how course material usually frames ACI. It is often described as a good fit for lift-and-shift migration, and that framing doesn't survive much scrutiny: lift-and-shift normally means an application that hasn't been containerised at all, which is precisely the case that argues for VMs. ACI's real strength is short-lived and bursty container work, and treating it as a migration landing zone will disappoint.
Portability, and its limits
Containers bundle the application with its dependencies, so the same image runs consistently across environments, on-premises, other clouds or a developer's laptop. App Service is tightly integrated into Azure, which is exactly what makes it convenient and exactly what limits multi-cloud flexibility at the same time.
Worth being honest about how much this matters. Image portability is real; the surrounding platform is where the lock-in actually lives. An AKS workload that leans on Azure-managed identities, Azure CNI, Application Gateway ingress, and Key Vault CSI drivers is not meaningfully more portable than an App Service app. Portability is a property of how you build, not just of whether you containerise.
The networking model is the part you can't cheaply undo
If there's one input that deserves more weight than it usually gets, it's the networking design. Microsoft's own guidance on selecting a container service singles it out: networking is a foundational infrastructure layer, and changes to it are often impossible without redeploying the workload and taking downtime.
The three models differ substantially. Container Apps is a PaaS offering with Azure-managed networking: service discovery, internal managed domains, virtual network controls. AKS is the most configurable and gives the most control over network flow, including custom ingress controllers and intra-cluster traffic control via Kubernetes network policy. Web App for Containers follows App Service's networking architecture, which is familiar if you already run App Service. Microsoft explicitly recommends Container Apps over Web App for Containers for teams who want conventional virtual network integration without prior App Service experience.
One specific constraint worth knowing before you commit: each Container Apps environment is limited to a single ingress IP address, either public or private. If you need both, you need an additional appliance in front — Application Gateway or Front Door — or separate environments, each with its own subnet. That's a design decision, not a setting.
Pricing tiers and instance counts can be changed in seconds. Subnet sizing and ingress topology cannot. Decide the second one first.
A concrete example of the trade-off
Oracle WebLogic makes the abstraction boundary tangible. You can run WebLogic on AKS — Microsoft and Oracle jointly publish an Azure Marketplace offer that provisions an AKS cluster, the WebLogic Kubernetes Operator, the WebLogic Server images, and a container registry — and you can run it on Azure VMs. You cannot run it on App Service.
The reason is the useful part. WebLogic is a clustered, stateful Java EE application server that expects to manage domains, node managers, and cluster membership itself. It needs an operator to reconcile that state, which means it needs the Kubernetes API. App Service's model — here is your code, we will run it on instances we manage — has nowhere to put an operator. This is what "more control" actually means in practice: not a preference for knobs, but a workload whose architecture requires them.