Azure Functions is the serverless compute service of Microsoft Azure that runs small units of code, called functions, in response to triggers such as HTTP requests, queue messages, timers or database changes. Azure manages the servers, the runtime and automatic scaling, so developers deploy only code and configuration, and on consumption-based plans pay mainly for executions and resources actually used.
In serverless computing, Azure Functions is the Azure counterpart of AWS Lambda, and it belongs to the function as a service model. Its distinguishing features are declarative bindings that connect code to other services without boilerplate, a choice of hosting plans with different scaling and networking behavior, and the Durable Functions extension for stateful workflows.
How Azure Functions executes code
Functions are grouped into a function app, the unit of deployment, configuration and scaling. Every function has exactly one trigger, which defines the event that starts a function invocation, and any number of input and output bindings. A binding lets the runtime read a blob, write a queue message or update a database record on behalf of the code, so the function receives ready-made parameters instead of opening connections itself.
The Functions host runs on each instance, listens for events and calls the code. A component called the scale controller monitors event sources such as queue length or incoming HTTP rate and adds or removes instances. On consumption-based plans, an idle app can scale to zero, which means the next event pays a cold start penalty while an instance and the language worker start.
| Trigger | Event source | Typical use |
|---|---|---|
| HTTP trigger | Incoming web requests | APIs and webhooks |
| Timer trigger | CRON-style schedule | Cleanup and periodic reports |
| Queue and Service Bus | Messages in a queue or topic | Background processing |
| Blob trigger | New or changed files in storage | Image and document processing |
| Event Grid and Event Hubs | Platform events and streams | Event-driven integration, telemetry |
| Cosmos DB trigger | Change feed of a container | Reacting to data changes |
Hosting plans and their parameters
The hosting plan decides how an app scales, how long functions may run and whether it can reach private networks. Choosing the plan is the most consequential configuration decision.
| Plan | Scaling behavior | Key characteristics |
|---|---|---|
| Flex Consumption | Per-function fast scaling, scale to zero | Pay per use, optional always-ready instances, virtual network support |
| Consumption | Event-driven, scale to zero | Original pay-per-execution plan, short timeouts, cold starts |
| Premium | Event-driven with prewarmed instances | No cold start on warm instances, longer runs, virtual network |
| Dedicated (App Service) | Manual or autoscale rules | Predictable cost on existing App Service capacity |
| Container Apps | Event-driven container scaling | Functions packaged as containers |
Execution time limits differ by plan. The classic Consumption plan allows a default of 5 minutes and a maximum of 10 minutes per execution, while Premium and Dedicated plans support much longer runs. Independently of the plan, an HTTP-triggered function must answer within about 230 seconds because of the front-end load balancer timeout, so long work should be handed off to a queue or an orchestration.
Azure Functions compared with other serverless options
Azure Functions shares the core model of other function platforms but differs in bindings, hosting flexibility and stateful orchestration. The comparison below places it among neighboring services.
| Service | Unit of deployment | Notable difference |
|---|---|---|
| Azure Functions | Function app with triggers and bindings | Declarative bindings, multiple hosting plans |
| AWS Lambda | Individual function or container image | Integrations configured as event source mappings |
| Google Cloud Run | Container serving HTTP or events | Any container, request concurrency per instance |
| Cloudflare Workers | Script running at edge locations | Lightweight isolates with very low startup time |
| Azure Container Apps | Containerized microservices | Long-running services with event-driven scaling |
Durable Functions is a decisive differentiator. It lets developers write orchestrator functions in ordinary code that call activity functions, wait for external events, fan out work in parallel and survive restarts. The runtime persists orchestration history in storage and replays the orchestrator to rebuild state, which imposes the rule that orchestrator code must be deterministic.
Languages, runtime models and configuration
Azure Functions supports C#, JavaScript, TypeScript, Python, Java and PowerShell, and other languages through custom handlers that receive events over HTTP. For .NET, the recommended approach is the isolated worker model, where function code runs in a separate process from the host, giving independent control over .NET versions and dependencies.
- host.json holds app-wide settings such as logging, extension options and the function timeout.
- Application settings supply connection strings and secrets, ideally through managed identity and Key Vault references.
- Deployment slots on supporting plans allow staged releases and swaps.
- Application Insights collects invocations, dependencies, failures and performance data.
Limitations and common design mistakes
Most problems with Azure Functions come from treating functions like long-running servers. Functions should be short, stateless and idempotent, because triggers such as queues deliver messages at least once and retries can execute the same event twice.
| Mistake | Consequence | Remedy |
|---|---|---|
| Creating a new client per invocation | Socket exhaustion under load | Reuse static or injected clients |
| Long synchronous HTTP work | Timeouts near 230 seconds | Queue the work or use Durable Functions |
| Non-idempotent queue handlers | Duplicate side effects on retry | Use idempotency keys and checks |
| Ignoring cold starts | Slow first requests after idle periods | Always-ready or prewarmed instances |
| Unbounded scale-out | Overloading a downstream database | Limit maximum instances and concurrency |
Cost can also surprise teams. Consumption pricing is very cheap for sporadic workloads, but a function that runs constantly at high volume may cost less on a Premium or Dedicated plan, so steady high utilization favors reserved capacity.
A plain-language summary
Azure Functions lets a company run small pieces of code only when something happens, without managing any servers. A file is uploaded, an order arrives or a clock reaches midnight, and the right piece of code starts, does its job and stops.
It is similar to hiring help by the task instead of keeping staff on duty all day. When there is nothing to do, almost nothing is paid; when work piles up, more helpers appear automatically. The trade-off is that a helper called after a quiet period may need a moment to arrive.
An example from practice
A regional insurance company receives scanned claim documents through a web portal. The development team builds a function app on the Flex Consumption plan: a blob trigger starts a function whenever a new PDF lands in storage, the function extracts text, and an output binding writes a message to a queue for review.
A Durable Functions orchestration then coordinates the next steps, waiting up to several days for an adjuster’s approval event before generating a payment record. During storm seasons, uploads rise from hundreds to tens of thousands per day, and the app scales out automatically without changes. In quiet weeks it scales to near zero, and the company pays only for the processing actually done.