Azure Functions is an event-driven, serverless compute service that runs small units of code in response to things that happen.

The Simple Definition

Serverless does not mean there are no servers. It means you do not manage them. Azure Functions belongs to a family called Functions as a Service. You write a function, which is a small piece of code with one clear job. You attach a trigger, which is the event that starts it, such as an incoming web request, a new message in a queue, a timer that fires every night, or a file that lands in storage. The platform handles everything between the event and your code: finding capacity, starting a runtime, passing in the data and collecting the result.

It exists because many tasks are bursty and small. Sending a welcome email after sign-up, resizing an uploaded picture, processing one sensor reading, or calling a partner system every hour are all jobs that do not justify an always-running server. It is used for back-end APIs, data processing, scheduled jobs, integration glue between systems and long-running business workflows.

What You Manage and What Microsoft Manages

Microsoft owns the datacenter, the host machines, the operating system, the runtime patching and the machinery that watches for events and adds workers. You own the code, the configuration, the identity and permissions, the data it touches, the network design and the cost decisions. The less you manage, the more you must understand the rules of the platform, because the platform makes decisions on your behalf, such as when to start and stop workers.

Where Functions Fit Among Azure Compute Choices

Functions sit at the small, event-driven end of the compute family. App Service suits full web applications. Container Apps suits containerized microservices. Kubernetes suits large platforms with deep orchestration needs. Logic Apps suits low-code business workflows with many ready-made connectors. Functions is the natural choice when the work is naturally triggered by an event and can be written as small pieces of code.

Ten terms appear in nearly every conversation about Azure Functions. Learn them once and everything else becomes easier.

One Trigger, Many Bindings

The rule that every function has exactly one trigger but any number of bindings is important. The trigger answers the question: what wakes me up? The bindings answer: what else do I read from, and where do I write? A function can wake up on a queue message, read a record from a database through an input binding and write a result to blob storage through an output binding, all without opening a single connection in your own code.

The Function App Is the Real Unit of Scale

Beginners often assume each function scales on its own. On most plans, it is the function app that scales: all functions inside an app are loaded on the same instances and share their memory and CPU. That is why putting a heavy, slow function and a tiny fast function in one app can make the tiny one suffer. One notable exception exists in the newest serverless plan, which scales certain groups of functions independently, as we will see in the scaling chapter.

A look at the parts that sit between an event and your code.

The Big Picture

Behind a function app there are several cooperating parts. Event sources produce events. The scale controller monitors those sources and decides how many instances are needed. Each instance runs the host, which listens to the event sources, and a language worker, which runs your code. A storage account stores bookkeeping the host needs, such as coordination locks, timer state and, for some features, deployment content. Application Insights receives telemetry. Together these parts make the illusion that your code simply runs whenever needed.

flowchart TD
  SRC["Event Sources: queues, topics, streams, HTTP, timers"] --> SC["Scale Controller"]
  SC -->|"adds or removes"| I1["Instance 1"]
  SC -->|"adds or removes"| I2["Instance 2"]
  SC -->|"adds or removes"| I3["Instance N"]
  I1 --> H1["Host and Language Worker"]
  I2 --> H2["Host and Language Worker"]
  I3 --> H3["Host and Language Worker"]
  H1 --> ST["Storage Account for coordination and state"]
  H2 --> ST
  H3 --> ST
  H1 --> AI["Application Insights"]
  H2 --> AI
  H3 --> AI
  H1 --> OUT["Output targets: databases, storage, services"]
        

The Host: Stage Manager

The host is the process that knows how to listen. For a queue trigger, it opens a listener on the queue, pulls messages in batches and hands each message to your function. For a timer trigger, it keeps track of the schedule and fires at the right moments. For HTTP, it receives requests and routes them. The host also applies your retry rules, enforces timeouts, loads extensions and emits logs. Most surprising behaviors in Functions are really host behaviors.

The Isolated Worker Model

In the modern model, your code runs in its own process, separate from the host. This gives you control over dependencies and runtime versions, a standard programming model, and fewer clashes with the host’s own libraries. Newer plans support only this isolated model for .NET. The older in-process model, where your code loaded into the host’s own process, is being phased out, so new projects should choose isolated from the start.

The Storage Account: Shared Notebook

Most function apps need a storage account. The host uses it to coordinate between instances, for example deciding which instance owns a timer schedule or which instance processes a given partition. Some plans also keep your deployment package there. If this storage account is slow, throttled, blocked by firewall rules or deleted, the entire app misbehaves, so treat it as critical infrastructure and never share it blindly across unrelated apps.

Runtime Versions, Language Versions and Extension Bundles

Three version numbers shape every function app. The host runtime version decides which platform features exist. The language version, such as a specific release of .NET, Java, Node.js or Python, decides which libraries and syntax you may use. The extension bundle version decides which trigger and binding behaviors are available. Each moves on its own schedule, and old versions eventually lose support. Treat versions as part of your maintenance calendar: review them every quarter, test upgrades in a copy of the app, and never discover a retirement notice on the day it takes effect.

The newest serverless plan, for example, supports modern long-term releases of several languages and only the isolated model for .NET. An app written for an older model cannot simply be switched over, so build upgrade time into your plans rather than treating it as a surprise.

Following one message from birth to completion shows where time, failures and duplicates come from.

sequenceDiagram
  participant P as Producer
  participant Q as Queue or Stream
  participant SC as Scale Controller
  participant H as Host on Instance
  participant F as Your Function
  participant D as Downstream Service
  P->>Q: Publish event
  SC->>Q: Observe backlog and rate
  SC->>H: Ensure enough instances
  H->>Q: Pull batch of events
  H->>F: Invoke with event data
  F->>D: Do the work
  D-->>F: Result
  F-->>H: Success
  H->>Q: Mark complete or checkpoint
        

At-Least-Once Delivery: The Rule That Surprises Everyone

Most triggers promise at-least-once delivery. That means an event will certainly be given to your function, but in rare moments it may be given more than once. A worker can crash after your code finishes but before the completion is recorded. When the event becomes visible again, another worker processes it a second time. Exactly-once processing across distributed systems is extremely hard, so the platform chooses the safer promise: never lose, sometimes repeat.

Cold Starts

A cold start happens when an event arrives and no instance is ready. The platform must allocate capacity, start the host and the language worker, and load your code before it can run. Cold starts depend on language, package size, startup work and the hosting plan. They matter most for user-facing HTTP calls and matter little for background queue processing. Plans with always-ready or prewarmed instances reduce or remove them, at a baseline cost.

The HTTP Time Limit

Regardless of hosting plan, an HTTP-triggered function must respond within about 230 seconds because the load balancer cuts idle connections after that time. Any task that may run longer should return early with an acknowledgement and continue in the background, using a queue or a durable workflow, and let the client check status later.

Graceful Shutdown and Scale-in

When the platform scales in or updates an instance, it asks the host to stop. The host stops taking new events and gives running invocations a grace period to finish. On the newer plans this grace period is generous, around an hour for scale-in, but it is not unlimited. If your function is still running when time runs out, it is cut off, the event is not marked complete and it will be delivered again. This is one more reason to keep each invocation short, make long work resumable and treat every run as something that might be interrupted halfway.

Checkpointing is the classic solution. Break a large job into small slices, record progress after each slice and let the next invocation continue from the last recorded position. A job that can be interrupted at any moment and resumed later is naturally robust against restarts, deployments and scale-in events.

The hosting plan decides your scale limits, cold-start behavior, networking options and bill. Choosing well is the biggest single decision.

The Five Options

Key Numbers Worth Remembering

Each trigger type has its own personality: how events arrive, how they are counted, how failures are handled and how scaling works.

The Common Triggers

Input and Output Bindings

Bindings reduce plumbing. An input binding fetches a document, a blob or a row before your code runs. An output binding writes a message, a document or a file after your code finishes. This keeps functions short and makes them easy to test. The trade-off is that bindings hide connection behavior, so for high-throughput or very custom needs, many teams create and reuse a client object themselves, which brings us to a key rule below.

Reuse Clients, Do Not Recreate Them

Each invocation is short, but the process that runs it lives longer. Creating a new connection to a database or a web service for every call wastes time and can exhaust available connections and network ports. Create clients once when the process starts and reuse them across invocations. This single habit prevents a large share of production problems in serverless code.

Ordering, Batching and Sessions

People often ask whether messages are processed in order. The honest answer depends on the trigger. Simple storage queues give no strict ordering promise. Service Bus can preserve order within a session, so all messages with the same session key are handled one after another by a single consumer, while different sessions are processed in parallel. Event Hubs preserve order within a partition, so choosing a good partition key, such as a customer or device identifier, keeps related events in sequence. If your logic truly needs global ordering, expect to give up parallelism and reconsider whether the design can tolerate slight reordering instead.

Batching is the other side of this coin. Many triggers can hand your function several events at once. Batches reduce overhead and let you write to a database in bulk, but one bad event inside a batch can cause the whole batch to be retried unless you handle partial failures deliberately. Decide per workload whether you prefer small batches with simple error handling or large batches with careful per-item tracking.

Scaling in Functions is automatic but not magical. Understanding its inputs lets you shape it instead of being surprised by it.

What the Scale Controller Looks At

The scale controller uses different signals for different triggers. For queues and topics, it looks at backlog size and the age of the oldest waiting message. For streams, it looks at how far behind each partition is. For HTTP, it looks at incoming request rate and the number of concurrent requests per instance. When backlog grows, it adds instances. When work falls, it removes them gradually and, on scale-to-zero plans, eventually to none.

Instances Versus Concurrency

Two knobs control how much work happens at once. Instances are the number of machines. Concurrency is how many invocations each instance runs in parallel. A single instance can often run many invocations at once, particularly when the work waits on network calls. Raising concurrency can reduce the number of instances needed for the same load, but it raises memory pressure and the load on downstream services. Newer plans offer per-function and per-trigger concurrency controls, and many triggers support target-based scaling, which computes the needed instances directly from the backlog and the target number of events each instance should handle.

flowchart LR
  B["Backlog or Request Rate"] --> SC["Scale Controller"]
  SC --> N["Needed Instances"]
  N --> L{"Within plan limits and quota?"}
  L -->|"yes"| ADD["Add instances"]
  L -->|"no"| CAP["Capped by maximum or regional quota"]
  ADD --> C["Each instance runs many invocations"]
  C --> D["Downstream database or API"]
  D -.-> PR["Pressure on dependencies"]
  PR -.-> LIM["Set maximum instances and concurrency to protect them"]
        

Per-Function Scaling on Flex Consumption

On the newest serverless plan, functions are grouped by trigger type for scaling. All HTTP-triggered functions scale together on shared instances, all blob-triggered functions that use Event Grid scale together, and durable function triggers scale together. Every other function scales on its own instances. This means a slow queue processor cannot starve a fast HTTP endpoint inside the same app, which was a real limitation in older plans. The maximum instance count applies per group, and always-ready instances are counted separately from that maximum.

Scale-Out Speed Is Not Instant

Scale-out is quick when the app is small and becomes more gradual as instance counts grow. Occasional throttling during scale-out is normal and the platform retries. If your workload has a sharp spike, such as a marketing e-mail that triggers a flood of calls in one minute, pre-scale with always-ready instances, use a queue to smooth the spike, or both.

Protecting What Sits Behind the Function

The cruel truth of serverless is that the function tier scales better than the database behind it. A thousand instances can open a thousand times more connections than a modest database accepts. Always set a maximum instance count, tune concurrency, use connection pooling, and put a queue between fast producers and slow dependencies. The platform will happily scale until something downstream breaks, unless you set boundaries.

A Practical Method for Tuning Scale

Reliable serverless code assumes that every step may fail and every message may arrive twice.

Idempotency: Making Repeats Harmless

An operation is idempotent when doing it twice has the same effect as doing it once. Setting a status to shipped is idempotent. Adding one to a counter is not. Because duplicates can occur, every function that changes the world should be designed so a repeat is harmless. Common techniques include using a unique event identifier and recording that it was processed, writing with upsert operations instead of blind inserts, and using conditional updates that check the current state first.

Retries

There are several layers of retry. The trigger itself may redeliver a message when a function fails. The host may apply a retry policy, with either a fixed delay or an exponential delay between attempts, for supported trigger types such as timers, Event Hubs and Cosmos DB. Your own code may retry calls to downstream services. When these layers combine, a single failure can multiply into many attempts, so keep an eye on the total. Always use delays that grow, limit the number of attempts and add a bit of randomness to avoid thundering herds.

Poison Messages and Dead-Lettering

A poison message is one that fails every time, perhaps because its content is malformed. Without a safety net, it would be retried forever and could block other messages. Messaging services handle this by moving the message aside after a maximum number of delivery attempts: Storage queues use a poison queue, and Service Bus uses a dead-letter queue. The critical operational step is to monitor those side queues, alert when they receive anything and have a procedure to inspect, fix and replay messages.

Streams Need Special Care

With a stream such as Event Hubs, one bad event inside a partition can block everything behind it if you retry forever, because the partition must be processed in order. You must decide deliberately: retry a limited number of times, then move the failed event to a side store for later analysis and continue. Silently skipping events loses data, and retrying forever stalls the partition, so pick a documented policy.

When work has many steps, waits, branches or human approvals, plain functions are not enough. Durable Functions adds memory to serverless code.

What Durable Functions Adds

Durable Functions is an extension that lets you write stateful workflows as ordinary code. An orchestrator function describes the steps, and activity functions do the actual work. The framework records progress in a durable store, so the workflow can pause for days, survive restarts and resume exactly where it stopped. This means you can express a multi-step business process in a readable sequence instead of scattering state across queues and tables.

The Main Patterns

flowchart TD
  C["Client request"] --> S["Starter function"]
  S --> O["Orchestrator"]
  O --> A1["Activity: validate order"]
  A1 --> O
  O --> F{"Fan out"}
  F --> A2["Activity: reserve item 1"]
  F --> A3["Activity: reserve item 2"]
  F --> A4["Activity: reserve item 3"]
  A2 --> J["Fan in and combine"]
  A3 --> J
  A4 --> J
  J --> H["Wait for human approval or timeout"]
  H --> A5["Activity: ship and notify"]
  S -.-> ST["Status address returned immediately"]
        

Replay: The Rule That Shapes Orchestrator Code

Durable orchestrations achieve their magic by replay. Each time an orchestrator needs to continue, the framework runs the orchestrator code again from the beginning, but returns the recorded results for steps that already completed instead of doing them again. The code reaches its previous position quickly and moves on. Because of this, orchestrator code must be deterministic: given the same history, it must make the same decisions every time.

Storage Providers and Limits

Orchestration state lives in a storage provider. On the newest serverless plan, supported choices are Azure Storage and the Durable Task Scheduler. Each choice has different throughput, cost and monitoring characteristics, so test with realistic volumes. Keep activity inputs and outputs small, because large payloads are stored in the history and slow replay. Store large data in blob storage and pass only references.

Sub-Orchestrations and Versioning

Large workflows are easier to understand when broken into smaller orchestrations that call each other, much like functions calling functions. A parent orchestration can start child orchestrations, wait for them and combine their results, and each child keeps its own history, which keeps individual histories small. This also helps when a rule needs different retry behavior for different parts of a process.

Versioning deserves planning before the first production release. Running orchestrations replay against the code that is deployed, so changing the order or number of steps in code can break orchestrations that were started before the change. Common strategies include letting old instances finish before releasing breaking changes, creating a new orchestration name for the new logic while the old one drains, and carrying a version number in the input so the code can branch deliberately. Choose one strategy and document it for the whole team.

Timers, Timeouts and Escalation

Durable timers make waiting free: while a workflow waits for an approval, no compute is running and no cost accrues. Combine a timer with an external event to build a deadline, so that if nobody approves within two days, the orchestration escalates, reminds or cancels automatically. Always cancel timers that are no longer needed, because an orphaned timer can keep an orchestration alive longer than expected.

Functions often need to reach private databases and sometimes need to be reachable only privately. Inbound and outbound are different problems with different tools.

Inbound and Outbound

Plan-Specific Facts

On Flex Consumption, outbound integration uses a subnet delegated to the Microsoft.App environments service, and the Microsoft.App resource provider must be registered in the subscription. Hybrid Connections, the relay-based way to reach a single on-premises host, are not available on that plan. On Premium, you also get the older delegation style and Hybrid Connections on Windows. The legacy Consumption plan has no virtual network support at all, which is a major reason teams migrate away from it. Container Apps supports outbound integration and service endpoints but not private endpoints for the function app itself.

flowchart TD
  U["Internal caller or API gateway"] --> PE["Private endpoint subnet"]
  PE --> FA["Function App"]
  FA --> INT["Integration subnet"]
  INT --> SQL["Private database"]
  INT --> KV["Key Vault with public access off"]
  INT --> SA["Storage account with private endpoints"]
  INT --> NAT["NAT gateway with fixed address"]
  NAT --> EXT["Partner API with allow list"]
  DNS["Private DNS zones"] -.-> PE
  DNS -.-> SA
        

Do Not Forget the Host Storage Account

If you lock the host storage account behind a firewall or private endpoints, the function app must be able to reach it through the integration subnet, with correct private DNS for every storage service the host uses, such as blob, queue and table. Many first attempts at private function apps fail because the host cannot reach its own storage, and the symptom is an app that will not start. Test connectivity of the storage account before locking down the rest.

Subnet Planning

Integration subnets must be large enough for peak instance counts plus room for platform updates. On plans that can scale to hundreds of instances, a small subnet can stop scale-out in confusing ways. Plan address space early, avoid ranges that overlap with on-premises networks, and keep private endpoint subnets separate from integration subnets.

Good function apps keep code, settings and secrets apart, and avoid passwords wherever an identity can do the job.

Application Settings

Application settings are named values the platform injects into your function app as environment variables. They let the same code behave differently in development, staging and production without rebuilding. They are encrypted at rest and can be changed without redeploying, although a change restarts the app. Many trigger and binding settings, such as the name of a queue connection, are also read from application settings, so naming discipline pays off.

Identity-Based Connections

Historically, connections to storage, messaging and databases used connection strings that contained secret keys. A better approach is identity-based connections. The function app has a managed identity, an account in Microsoft Entra ID that Azure creates and rotates for you. You grant that identity permission on the target service, for example the right to receive messages from a Service Bus queue, and then configure the connection by pointing to the service address rather than supplying a secret. Many core triggers and bindings, including storage, Service Bus, Event Hubs and Cosmos DB, support this model, as does the host’s own storage account connection.

Key Vault References

Some secrets cannot be replaced by identity, such as a third-party API key. Store those in Azure Key Vault and place a reference in the application setting. At runtime, the platform fetches the real value using the app’s managed identity. The secret never appears in your repository, your pipeline or the settings screen, and rotation becomes a vault task.

flowchart LR
  FA["Function App"] -->|"asks for token"| MI["Managed identity endpoint"]
  MI --> ENTRA["Microsoft Entra ID"]
  ENTRA -->|"short lived token"| FA
  FA -->|"token"| SB["Service Bus"]
  FA -->|"token"| COS["Cosmos DB"]
  FA -->|"token"| ST["Storage"]
  FA -->|"vault reference"| KV["Key Vault"]
        

System-Assigned or User-Assigned

A system-assigned identity is created with the app and deleted with it. A user-assigned identity is a standalone resource that can be shared by several apps or recreated alongside a replacement app. User-assigned identities are handy when you want permissions to survive redeployment of an app or share one identity across a set of closely related apps, but remember that a shared identity widens the blast radius if one app is compromised.

Least Privilege in Practice

Give the identity only the narrowest role at the narrowest scope. A function that only reads from one queue should have a receiver role on that queue, not an owner role on the namespace. Separate identities per environment prevent a bug in staging from touching production data.

No single setting secures a function app. Layers do.

Function Keys Are Not User Authentication

HTTP functions have an authorization level. Anonymous allows anyone. The function level requires a key, and the admin level requires a master key. Keys are shared secrets that identify an application caller, not a person, and they cannot express who a user is or what that user may do. For real user sign-in, use the platform’s built-in authentication with Microsoft Entra ID or another provider, or place the app behind an API gateway that validates tokens. Authorization decisions, such as roles and data ownership, still belong in your code.

The Layers

Supply Chain and Code

Serverless code often pulls in many third-party packages. Pin versions, scan dependencies for known vulnerabilities, keep runtime versions current and rebuild regularly. A forgotten library with a known flaw is as dangerous inside a function as anywhere else, and many small functions can multiply the number of places where an outdated package hides.

Cross-Origin and Browser Concerns

If a browser application calls your HTTP functions directly, configure allowed origins carefully and avoid wildcards for APIs that return user data. Send security headers from the gateway or from your code to reduce browser-based attacks.

Secrets Rotation and Key Hygiene

Even when most access uses identities, some keys still exist: function keys for server callers, signing keys for webhooks and third-party API credentials. Give each caller its own key instead of sharing one, so a single leak can be revoked without breaking everyone. Rotate keys on a schedule and after every staff change that touched them, store them only in a vault and record which system uses which key. Review access logs regularly for keys that are no longer used, and remove them, because every forgotten credential is an open door waiting for the wrong visitor.

Treat webhook endpoints with extra suspicion, since they are reachable by design. Verify signatures supplied by the sender, reject requests with old timestamps to stop replay attacks, and limit the size and rate of incoming payloads before any expensive work begins.

Shipping new function versions safely is trickier than shipping a web app, because background triggers keep running during the release.

How Code Reaches a Function App

Most teams deploy through a pipeline that builds, tests and publishes one immutable package. The app then runs directly from that package. On Flex Consumption, the package is a compressed archive uploaded to a blob container, and the app runs from it at startup, with the default being the host storage account, though you may choose a different account and authentication method. Container-based apps deploy an image from a registry instead.

Slots and Their Limits

Deployment slots, which let you stage a new version and swap it into production, are available on Premium, with a small number allowed, and on Dedicated plans, with more on higher tiers. The legacy Consumption plan offers only a couple, and the Flex Consumption plan has no slots at all, though a zero-downtime rolling update option is in public preview. When slots are not available, the usual approach is to deploy a complete second function app and switch traffic at a gateway, or to rely on rolling updates and idempotent processing.

The Hidden Danger: Triggers in Every Slot

A staging slot is a real, running function app. If its queue trigger points at the same queue as production, it will compete with production for messages and process live work with unfinished code. The same is true for timers and change feed triggers. Always give slots their own trigger sources through slot-specific settings, or disable the triggers in staging until the swap. Forgetting this is one of the most expensive mistakes in serverless releases.

flowchart LR
  CI["Pipeline builds one package"] --> STG["Staging slot or second app"]
  STG --> T["Smoke tests with test queues"]
  T --> SW["Swap or traffic switch"]
  SW --> PROD["Production"]
  PROD --> OLD["Previous version kept for rollback"]
  STG -.-> RISK["Risk: staging triggers may consume production events"]
  RISK -.-> FIX["Fix: separate trigger sources or disable triggers until swap"]
        

Versioning Messages

During a release, old and new instances run side by side for a while, and queues may contain messages written by either version. Keep message formats backward and forward compatible: add fields instead of renaming them, ignore unknown fields and include a version number. This is the same expand and contract discipline used for databases.

Infrastructure as Code

Define function apps, plans, identities, networking and monitoring in repeatable templates. Because serverless systems consist of many small connected resources, manual configuration drifts quickly, and a template is the only reliable way to recreate an environment or review a change before it happens.

Testing Strategy for Functions

Functions are easy to run locally with the command-line tools and a storage emulator, which makes the inner loop fast. Good teams build three layers of tests. Unit tests check the business logic with no cloud dependencies, by keeping the function body thin and moving real logic into ordinary classes or modules. Integration tests run the function against real or emulated queues, storage and databases to prove that bindings, serialization and settings work. End-to-end tests run in a real cloud environment with real identities and networking, because many problems, such as permissions, private DNS and quotas, appear only there.

Event-driven systems fail quietly. Without good signals, a stuck queue can go unnoticed for days.

Three Kinds of Signals

Application Insights

Application Insights is the standard telemetry service for Functions. It records each invocation, its duration and result, outgoing dependency calls, exceptions and custom events. It also draws a map of how functions and services call each other. Enable it from day one, because history is most valuable on the day something breaks.

Sampling and Cost of Logs

Serverless apps can produce enormous numbers of invocations, and logging each one in detail can cost more than the compute. Sampling keeps a representative portion of telemetry while preserving counts. Tune log levels in the host settings so that noisy informational lines are reduced in production, but never sample away errors. A common mistake is to switch off logging to save money and then be blind during an outage.

What to Watch

Tracing Across Functions

When one event passes through several functions and queues, pass a correlation identifier along with each message and write it in every log line. Without it, reconstructing the journey of a single order across five functions feels like following footprints through a rainstorm.

Patterns are proven shapes. Anti-patterns are the shapes that keep causing incidents.

Helpful Patterns

Anti-patterns to Avoid

Serverless bills follow behavior. Understanding what is billed lets you shape the bill instead of fearing it.

How Each Plan Bills

Where the Money Really Goes

Compute is only one part. Executions that wait on slow dependencies are billed for their waiting time. Detailed logging can cost as much as compute. Storage transactions from the host and from durable workflows add up quickly under heavy load. Data leaving a region, private endpoints, firewalls and gateways also add charges. A runaway loop is the single most expensive failure, because automatic scaling turns a small bug into a large bill.

Levers to Spend Less

The Break-even Question

Serverless on-demand is cheapest for spiky or low traffic. As traffic becomes steady and high, a baseline plan such as Premium or Dedicated can become cheaper per request, because you pay for capacity that is always busy. Estimate your monthly execution count, average duration and memory, compare plans in the pricing calculator and revisit the decision as traffic grows.

Governance Basics

Use Azure Policy to require HTTPS only, restrict public access where it should not exist and enforce minimum TLS. Tag every function app with owner, product and cost center. Use role-based access control so only a few people can create expensive plans or change networking. Set budgets and anomaly alerts so surprise spend becomes a notification, not a month-end shock.

A Worked Cost Thought Experiment

Imagine a function that runs two million times a month, each run taking half a second on a mid-sized instance. On an on-demand serverless plan, you pay mainly for the memory-time of those one million seconds plus the per-execution charge, and a monthly free grant offsets a part of it. Now imagine the same function receives a steady stream all day, so instances would be busy almost continuously. A plan with a fixed baseline, where you pay for capacity whether or not it is used, may now cost less because the capacity is always working. The point is not the exact numbers, which change with region and time, but the method: estimate executions, duration and memory, price both models in the calculator and compare at your real traffic level.

Remember to include the supporting costs in the comparison. Logging volume, storage transactions from the host and durable workflows, private endpoints, gateways and outbound data transfer can together equal or exceed the compute charge, especially for tiny, very frequent functions.

Patterns become clear when you see how different organizations shape the same service for different goals.

Industry Scenarios

Functions Versus Other Choices

Moving From Older Plans or Servers

Many teams migrate workers that run on virtual machines, scheduled tasks or the legacy Consumption plan. A calm migration assesses triggers, dependencies and network needs, fixes blockers such as local file state, builds the target with templates, runs old and new side by side with separate trigger sources, switches gradually and retires the old system only after a full business cycle. Because an app cannot be converted in place between some plans, treat each move as a fresh deployment with a data and trigger cutover plan.

A compact checklist for design reviews.

A Maturity Ladder

Short, practical answers to questions that come up again and again.

No. Each function has exactly one trigger. If two events need the same logic, create two small functions that share common code.

Most triggers guarantee at-least-once delivery. A crash or timeout before completion is recorded causes redelivery. Make your function idempotent so repeats are harmless.

A cold start occurred because no instance was ready. Use always-ready instances, Premium prewarmed workers, a smaller package and lighter startup work for latency-sensitive functions.

Microsoft recommends Flex Consumption for new serverless apps. Choose Premium for steady traffic with always-warm capacity and richer options, Dedicated to reuse existing App Service capacity, and Container Apps if you standardize on containers.

Plans allow long execution timeouts, but an HTTP response must still be sent within about 230 seconds because of the load balancer idle limit. Use an asynchronous pattern for longer work.

Automatic scale-out raised concurrency beyond what the database accepts. Cap maximum instances, tune per-instance concurrency, pool connections and use a queue to smooth bursts.

No. Slots exist on Premium and Dedicated plans and in limited numbers on legacy Consumption, but not on Flex Consumption. Use a second app or rolling updates instead, and keep staging triggers away from production events.

No. Keys identify an application caller and can leak. Use token-based authentication for users and keep keys for server-to-server calls behind additional controls.

The most common cause is that the host cannot reach its storage account through the private network, often because private DNS for blob, queue or table is missing. Verify storage access and DNS first.

When a process has several steps, waits, parallel branches, retries with state or human approvals. For a single short task, a plain function is simpler.

Running orchestrations replay against recorded history. A code change that alters the sequence of steps breaks that match. Plan versioning, or let old instances finish before deploying breaking changes.

A serverless plan with identity-based connections, a maximum instance setting, Application Insights with sampling, dead-letter alerts and an execution-count alert. Add always-ready capacity or private networking only where the workload demands it.

Azure Functions gives you on-demand workers that appear when events arrive and vanish when work ends. Behind the simplicity sit a host, a scale controller, a storage account and a set of rules that every serious builder should know. Delivery is at least once, so idempotency is not optional. Scaling is automatic, so you must set boundaries that protect your dependencies and your budget. Hosting plans differ sharply in cold starts, networking and billing, and Flex Consumption is now the recommended serverless choice while older Consumption plans are being retired. Durable Functions turns fragile chains of queues into readable stateful workflows. Identity beats passwords, private networking needs private DNS, and observability must watch backlog, not just exceptions.