Azure Functions vs Azure App Service
Azure Functions and Azure App Service are both hosted on the same underlying App Service platform, but they use fundamentally different programming models and billing structures. Understanding when each is the right tool — and when a hybrid approach makes sense — is one of the most common architectural decisions in Azure application development.
What each service provides
Azure App Service is a managed platform for hosting web applications, REST APIs, and mobile backends. You deploy an application — a Node.js Express server, an ASP.NET Core web app, a Django application, a PHP site — and App Service keeps it running as a persistent process. It handles load balancing, SSL, deployment slots, and custom domains. You choose a plan (Free, B1, B2, P1v3, etc.) that determines the CPU, memory, and autoscaling options.
Azure Functions is a function execution platform. You write individual functions triggered by events (HTTP, queue messages, timers, blob uploads). Functions runs each invocation as an isolated execution, manages the trigger infrastructure, and (on Consumption plan) scales the execution environment in response to demand. The programming model is individual functions rather than a persistent web application.
Comparison across key dimensions
| Dimension | Azure Functions (Consumption) | Azure App Service (B1 plan) |
|---|---|---|
| Billing model | Per execution + per GB-second | Fixed monthly plan cost (~$13/month for B1) |
| Idle cost | $0 (scales to zero) | Full plan cost even with zero traffic |
| Cold start latency | 200ms–2s after idle | None (always-on) — warm-up slots available on Standard+ |
| Autoscaling | Automatic, to hundreds of instances | Manual or rules-based autoscale (Standard+ tier) |
| Scale to zero | Yes | No |
| WebSocket / SignalR | Not natively supported (use Durable Functions with Azure SignalR Service) | Fully supported |
| Background threads / long tasks | Limited — Consumption plan max 10 min; Premium max 60 min | No limit — persistent process runs indefinitely |
| Deployment workflow | Code package, container image, or CI/CD pipeline | Code package, container image, ZIP deploy, Git, CI/CD |
| Custom domains + SSL | Supported (Custom plan or Function App built-in) | Supported from Basic tier upwards |
| Deployment slots | Supported (Premium and Dedicated plans) | Supported from Standard tier upwards |
Billing model implications
App Service bills a flat monthly rate based on the plan you choose. A B1 plan (1 vCPU, 1.75 GiB RAM) costs approximately $13/month. A P1v3 plan (2 vCPUs, 8 GiB RAM) costs approximately $139/month. These charges apply whether or not the application is handling traffic.
Azure Functions Consumption plan bills only when code runs: $0.20 per million executions (first 1M free) plus $0.000016 per GB-second of execution (first 400,000 GB-seconds free). For an HTTP API processing 5 million requests per month at 100ms average duration and 512 MB memory, the monthly cost is approximately: 4M paid executions × $0.20/M = $0.80 + 250,000 GB-seconds × $0.000016 = $4.00. Total: ~$4.80/month — cheaper than a B1 App Service plan.
However, at higher traffic the equation reverses. At 50 million requests per month (same parameters): ~$49M executions × $0.20/M = $9.80 + ~2.5M GB-seconds × $0.000016 = $40. Total: ~$50/month — much more than a B1 plan but possibly comparable to a B2 plan. At this scale, App Service is competitive or cheaper, and does not have cold starts.
App Service Premium v3 plans cost significantly more than Basic/Standard plans but include Zone Redundancy, more vCPUs, and enterprise features. Do not use the Free or D1 (Shared) plans for production workloads — they have no SLA and share resources across customers.
Scaling behaviour
Functions Consumption plan scales from zero to hundreds of instances automatically in response to demand. There is no configuration required. Each instance handles one invocation at a time by default (configurable via maxConcurrentRequests). Scaling happens in seconds — new instances are added as queue depth or request rate increases.
App Service Standard and Premium plans support autoscale rules based on CPU utilisation, memory, or HTTP queue depth. Autoscale adds or removes instances on the plan but is slower than Functions — new instances take 1–5 minutes to come online. App Service also supports Azure App Service Automatic Scaling (a simpler HTTP-based autoscale for P1v3+ plans) that is faster and requires less configuration.
For sudden traffic spikes — a viral marketing campaign, a scheduled event, or unpredictable burst traffic — Functions Consumption scales more responsively than App Service autoscale. For gradual, predictable growth, App Service autoscale is sufficient and avoids cold start issues.
The hybrid approach: Functions on App Service Plan
Azure Functions can be hosted on an existing App Service Plan. If you already run one or more App Service Web Apps on a Standard or Premium plan and have spare capacity, hosting Function Apps on the same plan adds no additional charge — the functions share the existing plan’s resources.
This hybrid approach is valuable when:
- You have background processing tasks (queue processors, scheduled jobs) that complement a web application and should share its plan
- Cold starts on Consumption plan are unacceptable but you do not want the cost of a separate Premium Functions plan
- Functions need VNet integration and you already have a Standard+ App Service Plan with VNet integration configured
The trade-off: functions on a shared plan consume CPU and memory resources that could otherwise serve web requests. Heavy function execution during peak web traffic can starve the web app. Monitor resource utilisation carefully on shared plans.
Use separate App Service Plans for background processing Functions and customer-facing Web Apps in production. The risk of resource contention between a batch processing function and a latency-sensitive API is real and often discovered during load testing rather than before it.
When to use each
Use Azure Functions when:
- The workload is event-driven — triggered by HTTP, queue messages, timers, or storage events
- Traffic is spiky or unpredictable and scale-to-zero cost savings are material
- Individual operations are short (under 10 minutes on Consumption plan)
- You want zero infrastructure management and the programming model fits
Use App Service when:
- The application is a full web framework (Express, Django, ASP.NET Core) with a persistent server model
- You need WebSocket or SignalR support for real-time communication
- Traffic is steady and predictable enough that a flat plan rate is cheaper than per-execution billing
- The application maintains in-memory state between requests (session state, in-process cache)
- You need App Service environment features: custom networking, compliance isolation (App Service Environment)
Common mistakes
- Running a full web framework on Azure Functions. Hosting an ASP.NET Core or Express app via a single HTTP-triggered Function works technically but loses the programming model benefits of each. Use App Service for full web frameworks and Functions for event-driven code.
- Choosing App Service for low-traffic APIs because cold starts on Functions seem risky. For APIs with low traffic, Consumption Functions almost always costs less. Address cold starts with a keep-warm timer trigger rather than paying for a permanently-on App Service Plan.
- Deploying CPU-intensive background jobs to a Function App on the same plan as a production web app. Resource contention is real. Heavy batch Functions on a shared plan can degrade web app response times during peak execution periods.
- Not using deployment slots for zero-downtime releases on App Service. App Service Standard and Premium plans include deployment slots. Swapping slots is the correct mechanism for zero-downtime deploys — restarting the production app in place causes a brief downtime during restart.
Summary
- Azure Functions Consumption plan is cheaper for low-to-moderate traffic but scales to zero; App Service charges a flat rate but has no cold start and supports persistent server workloads.
- App Service is the right choice for full web frameworks, WebSocket support, steady-traffic APIs, and workloads with in-memory state. Functions is right for event-driven, spiky, or short-duration workloads.
- Functions can run on an existing App Service Plan (Dedicated hosting), eliminating cold starts and sharing plan costs — but introduces resource contention risk on busy plans.
- For HTTP APIs at high steady traffic, App Service is often cheaper than Functions Consumption — model the cost before assuming serverless is cheaper.
Frequently asked questions
Can I run Azure Functions on an App Service Plan?
Yes. Azure Functions supports three hosting plans: Consumption (serverless), Premium, and Dedicated (App Service Plan). On Dedicated plan, your functions run on an App Service Plan that you already own, sharing resources with any App Service Web Apps on the same plan. This eliminates cold starts and gives functions the same always-on behaviour as App Service.
What is the difference between a Function App and an App Service Web App?
Both are hosted on the App Service platform, but a Function App uses the Azure Functions runtime and programming model (triggers, bindings, function-level isolation), while a Web App runs any web framework (ASP.NET, Django, Express, etc.) as a persistent process. A Web App handles requests via a running web server; a Function App handles them via individual function invocations.
Does App Service support scale-to-zero?
Standard and Premium App Service Plans do not scale to zero — you pay for the plan even with zero traffic. App Service on Linux has a Basic tier that supports auto-scaling but not to zero. Only Consumption-plan Azure Functions and Azure Container Apps scale to true zero. Premium App Service Plans have a minimum of one instance at all times.