App Service & Functions
Functions hosting plans · App Service tiers · Durable Functions · Logic Apps
Practice questions for this topic →
Azure Functions hosting plans
| Plan | Scale / billing | Cold start | VNet | OS | Pick when… |
|---|---|---|---|---|---|
| Flex Consumption (recommended serverless) | Event-driven to 1,000 instances; pay per use; memory 512 MB / 2,048 MB / 4,096 MB | Reduced with always-ready instances | Yes | Linux only | New serverless apps, variable load, VNet needed |
| Premium | Prewarmed workers, event-driven scale | None | Yes | Windows / Linux | Always warm, long runs, custom Linux image, several apps per plan |
| Dedicated (App Service plan) | Fixed price, manual or rule-based scale | N/A | Yes | Windows / Linux | Predictable billing, reuse an underused plan, ASE isolation |
| Container Apps | Functions beside other microservices, with automatic scaling | Scale to zero | Yes | Linux | Functions alongside other containers |
| Consumption (legacy) | Pay per execution | Yes | No | Windows (Linux retires Sep 30, 2028) | Only serverless option for Windows |
App Service tiers
| Tier | Compute | Key points |
|---|---|---|
| Free / Shared | Shared VMs with other customers' apps | CPU quotas per app; no scale-out |
| Basic / Standard / Premium v2, v3, v4 | Dedicated VMs (shared only by apps in the same plan) | More instances at higher tiers; Standard adds autoscale and deployment slots |
| Premium v4 | Faster CPUs, NVMe local storage, memory-optimized sizes | Windows code, Linux code and Linux containers; no Windows containers; no stable outbound IPs (use a NAT Gateway) |
| Isolated v2 / v4 (App Service Environment v3) | Dedicated VMs on dedicated virtual networks | Single tenant, compliance and high scale; Isolated v4 only on some ASE deployments and regions |
Facts to know
- Plans and apps: an app always runs in an App Service plan. With per-app scaling disabled, every app in the plan runs on every instance of the plan; per-app scaling lets an app or slot use a subset of the hosts.
- ASE v3 numbers: one ASE v3 supports up to 200 instances across all plans; one Isolated v2 plan supports up to 100. Typical reasons to choose an ASE: more than 30 plan instances, single-tenant compliance, network isolation, high memory or requests per second.
- Isolated v4 greyed out? The underlying ASE deployment or region doesn't support it. Check with
az appservice list-locations --sku I1V4. - Functions retirements: Linux Consumption retires Sep 30, 2028; apps still on the end-of-life v3 runtime on Linux Consumption stop running after Sep 30, 2026. Windows Consumption isn't affected; Flex Consumption is Linux-only, so Windows apps move to Linux when migrating.
- Durable Functions covers function chaining, fan-out/fan-in and waiting for external or human events. Logic Apps Standard runs single-tenant with VNet integration; Consumption is multitenant and billed per action.
Exam Tips
Tick each tip once you can answer it without looking.
“New serverless function app needs VNet access and pay-per-execution billing” → Flex Consumption plan. Trap: The Consumption plan is legacy and has no VNet integration.
“Functions must never cold start and run in a VNet” → Premium plan (prewarmed workers). Trap: Flex Consumption only reduces cold start when always-ready instances are configured.
“Serverless functions that must run on Windows” → Consumption plan (Windows). Trap: Flex Consumption is Linux-only.
“Predictable monthly cost, reuse an underused App Service plan” → Dedicated (App Service) plan.
“Stateful orchestration: function chaining, fan-out/fan-in, waiting for human approval” → Durable Functions. Trap: Chaining functions manually through queues isn't the expected answer.
“Low-code workflow using SaaS connectors (Office 365, Salesforce)” → Logic Apps. Trap: Standard runs single-tenant with VNet support; Consumption is multi-tenant, pay per action.
“Deploy to staging, test, then swap to production with instant rollback” → Deployment slots (Standard tier or higher). Trap: Basic has no slots.
“Web apps must be single-tenant, private and scale beyond 30 instances” → App Service Environment v3 (Isolated v2/v4).
“Premium v4 app needs a fixed outbound IP for a partner allow-list” → NAT Gateway. Trap: Premium v4 doesn't provide stable outbound IPs.
“App Service must call a database inside a VNet” → VNet integration (outbound). Trap: Making the app reachable only privately is a different feature: Private Endpoint (inbound).
“Five web apps share an App Service plan of three instances with per-app scaling off” → All five apps run on all three instances. Trap: Per-app scaling lets an app use only a subset of the plan's hosts.
“Instance ceilings to remember” → ASE v3 up to 200 instances across plans; one Isolated v2 plan up to 100. Trap: The usual reason to pick an ASE is more than 30 plan instances.
“Windows container web app on Premium v4” → Not supported: Premium v4 runs Windows code, and Linux code or containers. Trap: Isolated v4 (ASE v3) supports Windows containers, with caveats on large SKUs.
“Isolated v4 SKUs are greyed out” → The underlying ASE deployment or region doesn't support Isolated v4. Trap: Check with az appservice list-locations --sku I1V4.
“Free and Shared App Service tiers” → Shared VMs with other customers' apps, CPU quotas, no scale-out. Trap: Basic and above use dedicated VMs; Standard adds autoscale and slots.