Azure Functions vs ASP.NET Web API — when does each fit?
Both can serve HTTP endpoints. They are NOT substitutes. They sit on opposite ends of a trade-off between operational simplicity and runtime control.
The fundamental difference
- Web API runs as a long-lived process (Kestrel + your code on a VM / container). Always ready. You manage capacity, scale, deploys.
- Azure Functions is event-driven. Azure starts a function instance when something triggers it, then disposes the instance after some idle time. You write the function; Azure manages everything else.
Side-by-side
| Factor | Azure Functions (HTTP trigger) | ASP.NET Web API |
|---|---|---|
| Hosting | Serverless (Consumption / Premium) | VM / Container (App Service, Container Apps) |
| Cold start | 1-5 s (.NET on Consumption) | None |
| Idle cost | ₹0 (Consumption) | Cost of the VM |
| Sustained cost (100 RPS) | High (per-execution) | Lower (flat VM rate) |
| Max request duration | 10 min default, 60 min Premium | Unlimited |
| WebSockets / SignalR | Poor fit | Native |
| DI / middleware | Limited, function-scoped | Full ASP.NET Core stack |
| Routing | Per-function attributes | Conventional controllers |
| OpenAPI / Swagger | Via extensions | First-class |
| Auth | Function keys / AAD / custom | Identity, JWT, OAuth |
| Testing | Function-isolated unit tests | Standard MVC tests |
| Local dev | Functions Core Tools + emulators | dotnet run |
Decision rule
Pick Azure Functions when
- Workload is bursty (webhooks, queue spikes, scheduled jobs)
- Scale-to-zero matters for cost
- The job is event-driven (file uploaded → resize)
- Cold start latency is tolerable (or you're on Premium)
- The function is < 5 min execution
Pick ASP.NET Web API when
- Sustained traffic above ~30 RPS
- Rich middleware needs (auth, rate-limit, content negotiation)
- WebSockets / SignalR / streaming responses
- Long-running requests (> 10 min)
- You need OpenAPI for client SDK generation
- API is part of a larger system already on App Service
The cost crossover
Approximate break-even (Mumbai region prices):
Azure Functions Consumption: ~₹0.16/million execs + ~₹0.016/GB-sec memory
App Service Plan (P1v3): ~₹8,000-12,000/month flat (1 instance)
At ~30 RPS sustained → ~78M executions/month → ₹12-20K on Functions
~equal to App Service P1v3
Above 30 RPS → App Service is cheaper.
Below 30 RPS → Functions is cheaper.
What both can do
Both support DI, async, EF Core, structured logging, App Insights. Both deploy from the same CI/CD pipelines. Both can use the same DTOs, the same DB layer.
What only Web API can do well
- WebSockets / SignalR — long-lived connections
- Streaming responses (
IAsyncEnumerable<T>to client) - Per-request middleware (auth, CORS, request logging) in a unified pipeline
- Output caching, response compression, HTTPS redirection middleware
- Full
IHostedServicebackground work alongside the API
What only Functions can do well
- Trigger from Cosmos DB change feed, Service Bus, Event Grid, Blob Storage without polling
- Pay nothing when idle
- Scale 0 → 200 instances in seconds without manual capacity planning
- Durable Functions for orchestrated workflows (SAGA pattern as code)
Hybrid (the typical production setup)
Most real .NET systems use BOTH:
- Web API on App Service / Container Apps for the customer-facing REST API
- Azure Functions for webhooks, scheduled jobs, queue consumers, file processing
Same .NET project, same DI container, same DB layer. The choice is per-endpoint based on the workload shape.
Interview-grade summary
"Azure Functions is the right tool for event-driven, bursty workloads where scale-to-zero saves real money. Web API is the right tool for sustained-traffic HTTP APIs with middleware, auth, and ASP.NET ecosystem features. Most production systems use BOTH — Functions for triggers and cron jobs, Web API for the public REST surface. The cost crossover sits around 30 RPS sustained; below that, Functions usually wins; above, App Service is cheaper."