Azure Functions
Azure Functions runs a single piece of code in response to a trigger — an HTTP request, a timer, a new queue message, a blob upload — and bills only for the time that code executes. There are no servers to provision and, on the consumption plan, nothing to pay when no events arrive. It is the event-driven glue of an Azure architecture.
The trade for scale-to-zero economics is cold starts and execution limits. A function that has been idle pays a startup latency on the next request, and a function is not the place for a job that runs for an hour. Knowing the hosting plan and the execution model is what separates a cheap, responsive function app from a slow, surprising bill.
Triggers and Bindings
A trigger is what invokes the function — HTTP, Timer, Queue, Service Bus, Event Grid, Event Hub, or Blob. A binding is a declarative connection to data: an input binding fetches a document and hands it to your code, an output binding writes the return value to a queue or table, with no SDK code in between.
Bindings remove boilerplate, but they hide I/O. A function with three output bindings makes three service calls per invocation whether you think about them or not, and that shows up in both latency and cost. Treat each binding as the network call it is.
Azure FunctionsAzure runs your handler per eventHosting Plans
The hosting plan governs cold starts, networking, and price. Flex Consumption is the current default for new apps: it scales to zero, bills per execution, integrates with a VNet, and uses pre-provisioned (always-ready) instances to cut cold starts. The original Consumption plan is now the legacy option — it still scales to zero and bills per execution, but has no VNet integration and colder starts. Premium keeps instances always warm with VNet integration, for a strict latency SLO or heavy network isolation. Dedicated runs functions on an App Service plan you already pay for.
| Plan | Scales to zero | Cold starts | VNet |
|---|---|---|---|
| Consumption | Yes | Yes | No |
| Flex Consumption | Yes | Reduced (pre-provisioned) | Yes |
| Premium | No (always warm) | Eliminated | Yes |
| Dedicated | No | None | Yes |
Execution Model
A function is stateless and time-bounded. The Consumption plan caps a single execution at five minutes by default and ten at most; a function that needs to run longer belongs on a different plan or a different service entirely. State lives in storage between invocations, never in the function instance, because the instance can be recycled at any time.
Durable Functions
Durable Functions is an extension that adds stateful orchestration on top of stateless functions. An orchestrator function coordinates a workflow — fan-out/fan-in across many parallel activities, human-approval waits, retries with backoff — and Azure persists the orchestration state so it survives restarts. It is how you express a long-running, multi-step process without managing the state yourself.
Flex Consumption — Scales to zero, per-execution billing, VNet integration, reduced cold starts. The recommended default for new serverless apps.
Premium — Always-warm instances and VNet integration, billed for reserved capacity. Choose it for a strict latency SLO or heavy network isolation.
Consumption (legacy) — The original plan — scales to zero, no VNet, colder starts. Fine for simple existing apps; new apps should start on Flex Consumption.
- Running a long job on the consumption plan and hitting the execution timeout — the function is killed mid-run and the work is lost.
- Ignoring cold starts on a function behind a latency SLO — the first request after idle pays a multi-second startup the SLO does not allow.
- Choosing the legacy Consumption plan and then needing VNet integration it cannot provide — Flex Consumption supports VNet and should be the default for new apps.
- Treating a function as stateful — storing progress in instance memory that vanishes when the instance is recycled, instead of using Durable Functions.
- Adding output bindings without counting them — each is a network call, and a chatty function is a slow and expensive one.
- Building a multi-step workflow as a chain of functions calling each other over HTTP instead of a Durable orchestration that survives failures.
- Default new serverless apps to Flex Consumption; use Premium for a strict latency SLO or heavy network isolation, and the legacy Consumption plan only for simple existing apps.
- Keep functions short and single-purpose; move anything long-running to Durable Functions or Container Apps jobs.
- Store all state in external storage between invocations — never assume the instance persists.
- Use Durable Functions for fan-out/fan-in, approval waits, and any workflow that must survive a restart.
- Set min-instances on Premium for latency-sensitive endpoints to keep them warm.
- Pull connection strings and keys from Key Vault via a managed identity, not from app settings in plain text.
Knowledge Check
A function must run for 20 minutes per invocation. Why is the Consumption plan the wrong host?
- Consumption caps execution at ten minutes, so the run is killed before it finishes
- Consumption does not support timer triggers
- Consumption cannot write to storage
- Consumption charges a fixed flat monthly fee regardless of how often the function actually runs
What does Durable Functions add to the stateless function model?
- Stateful orchestration that survives restarts — fan-out/fan-in, waits, and retries
- A guaranteed elimination of all cold starts
- Direct VNet integration on the Consumption plan
- The ability to run any single uninterrupted execution for up to 24 hours on the Consumption plan
A latency-sensitive HTTP API is built on the Consumption plan and occasionally returns slow first responses. What is the most direct fix?
- Move to Premium (or set pre-provisioned instances) so instances stay warm and cold starts are eliminated
- Add more output bindings to parallelize the work
- Switch the trigger from HTTP to a queue
- Store warm state in instance memory between requests so each invocation can skip per-call re-initialization
What is the difference between a trigger and a binding?
- A trigger invokes the function; a binding is a declarative input or output data connection
- A trigger handles HTTP requests only, while a binding handles every other event source and protocol
- A trigger writes output; a binding starts the function
- They are two names for the same thing
You got correct