Azure App Service, Functions, and Container Services Compared

Azure App Service hosts long-running web apps and APIs as a fully managed platform, Azure Functions runs short-lived code that fires only in response to an event and bills for actual execution time, and container services package an application with its dependencies so it runs identically everywhere, with orchestration options ranging from a single instance to a full Kubernetes cluster. Picking between them comes down to how the workload runs — continuously, on trigger, or as a portable unit — and how much infrastructure control you actually want.

Azure App Service: managed web hosting

Azure App Service is a platform-as-a-service (PaaS) offering purpose-built for hosting web applications, REST APIs, and mobile app back ends — see IaaS vs PaaS vs SaaS for how that service model compares to running the same workload on a bare VM or consuming it as SaaS. Microsoft provisions and patches the underlying virtual machines and web server runtime, so you never touch the operating system directly — a sharp contrast to deploying the same workload on a bare VM or a VM Scale Set, where OS management stays on your plate. App Service still supports scaling as traffic grows, which makes it the common answer whenever a scenario wants a fast, low-maintenance way to stand up a customer-facing app without managing infrastructure.

One App Service capability worth knowing by name: deployment slots. A slot lets you stage a new version of an app in a separately addressable, production-like environment, validate it there, and then swap it into production with essentially no downtime. Whenever a scenario mentions testing a new version before it goes live with minimal disruption, deployment slots are the mechanism, not a scale set or an availability set — neither of which has anything to do with staged app deployment.

Azure Functions: serverless, event-triggered code

Azure Functions runs small pieces of code automatically in response to an event — a file landing in Blob Storage, an HTTP request, a queue message — without you provisioning or managing any servers. Billing follows a consumption model: you pay for the time the code actually executes, not for idle capacity. This is the answer whenever a scenario describes something that should “run only when a specific event happens” and explicitly wants to avoid always-on infrastructure, such as resizing an image the instant it’s uploaded or processing a new order document as soon as it arrives.

The hosting plan you choose changes the trade-offs. The Consumption plan scales from zero and is the source of cold-start latency, since new instances have to spin up when demand appears. The Premium plan keeps pre-warmed instances ready and supports virtual network integration, eliminating cold starts while retaining automatic scaling — the fit when a scenario needs VNet connectivity and can’t tolerate startup delay. The Dedicated (App Service) plan runs functions on pre-allocated, always-on compute at a fixed rate, which is the answer when a scenario describes constant, predictable, high-volume traffic and wants the most predictable monthly bill rather than consumption-based pricing. This event-driven, pay-for-what-you-use model is the same serverless billing pattern covered in Serverless Computing in Azure, just applied specifically to Functions here.

Containers: a lighter, portable unit

A container is a lightweight, portable unit that packages an application together with its dependencies while sharing the host operating system’s kernel — that shared kernel is exactly why containers start in seconds rather than the minutes a full VM boot can take, and why the same container image behaves identically on a developer’s laptop, in test, and in Azure production. Compared to deploying on a dedicated VM, containers give you faster startup and consistent portability across environments, though they don’t eliminate the underlying host OS dependency entirely — they just share it instead of duplicating it.

Azure gives you three main ways to run containers, each trading control for management overhead:

• Azure Container Instances (ACI) runs a single container directly on Azure infrastructure with no VMs to provision and no orchestrator to configure — the right call for a short, isolated burst job, like a CI/CD test step that needs to finish in seconds, or a one-off image-processing task.
• Azure Container Apps is a fully managed, serverless container platform that handles event-driven autoscaling for containerized microservices without exposing Kubernetes nodes, control-plane upgrades, or cluster management to you — the middle ground between ACI’s simplicity and full Kubernetes control.
• Azure Kubernetes Service (AKS) exposes a real, standard Kubernetes control plane, letting a platform team install custom controllers and operators and manage node pools directly. It’s the answer when a scenario demands direct API access or fine-grained orchestration control, not just autoscaling.

A related but distinct option, Azure Static Web Apps, is purpose-built to publish static front-end content (HTML, CSS, JavaScript) alongside an integrated serverless API back end — typically built on Azure Functions — in one streamlined build-and-deploy workflow. It’s the fit for a marketing site with a small contact-form API, not a general-purpose container or web-app host.

App Service vs. Functions vs. Containers

	Azure App Service	Azure Functions	Container platforms (ACI / Container Apps / AKS)
Runs continuously or on trigger	Continuously (long-running)	On trigger, event-driven	Continuously or on demand, depending on service
Billing model	Based on the App Service plan tier	Pay per execution (Consumption) or fixed (Premium/Dedicated)	Per-second (ACI) or cluster/plan-based (AKS, Container Apps)
Infrastructure control	None — fully managed platform	None — fully managed platform	Ranges from none (ACI, Container Apps) to full (AKS)
Best fit	Web apps, REST APIs, mobile back ends	Short, event-triggered functions	Portable, consistent deployment across environments

How the AZ-900 exam tests this

• A scenario wants a web app or API hosted without managing servers or OS patching, with the ability to scale — that’s Azure App Service, not a VM or VM Scale Set.
• A scenario describes code that “runs only when” an event occurs and wants to pay only for execution time — that’s Azure Functions; if it adds “no cold start” and “VNet connectivity,” the answer narrows to the Premium plan specifically.
• A scenario asks for a single, short-lived container with no orchestrator — Azure Container Instances. If it asks for autoscaling microservices without managing Kubernetes infrastructure, the answer shifts to Azure Container Apps. If it demands direct Kubernetes API access or custom operators, the answer becomes AKS.
• A scenario describes modernizing gradually — keeping a legacy app that needs full OS control while also deploying new containerized microservices with built-in orchestration — expect a two-part answer combining Azure Virtual Machines with AKS, since Functions and ACI can’t satisfy either requirement alone.

Quick reference

• App Service = managed hosting for continuously running web apps, APIs, and mobile back ends; use deployment slots to stage and swap releases with minimal downtime.
• Azure Functions = event-triggered, consumption-billed code; Premium plan removes cold starts and adds VNet support, Dedicated plan gives fixed-cost always-on compute.
• Containers share the host OS kernel, making them faster to start and more portable than VMs.
• ACI runs a single container with no orchestrator; Container Apps adds serverless autoscaling without cluster management; AKS gives full Kubernetes control.
• Azure Static Web Apps pairs static front-end hosting with a serverless API back end in one workflow.

For hands-on scenario practice distinguishing these compute options, work through AZ-900 practice questions that test exactly this kind of decision. And if your workload also needs steady-state compute with fault tolerance, see how VM Scale Sets and availability sets fit alongside these managed platform options. For how this compute decision fits into the exam as a whole, see the full AZ-900 study guide for how this fits into all three exam domains.