Durable Functions billing
Durable Functions is billed the same way as Azure Functions. For more information, see Azure Functions pricing.
When executing orchestrator functions in Azure Functions Consumption plan, you need to be aware of some billing behaviors. The following sections describe these behaviors and their effect in more detail.
Orchestrator function replay billing
Orchestrator functions might replay several times throughout the lifetime of an orchestration. Each replay is viewed by the Azure Functions runtime as a distinct function invocation. For this reason, in the Azure Functions Consumption plan you're billed for each replay of an orchestrator function. Other plan types don't charge for orchestrator function replay.
Awaiting and yielding in orchestrator functions
When an orchestrator function waits for an asynchronous task to complete, the runtime considers that particular function invocation to be finished. The billing for the orchestrator function stops at that point. It doesn't resume until the next orchestrator function replay. You aren't billed for any time spent awaiting or yielding in an orchestrator function.
Note
Functions calling other functions is considered by some to be a Serverless anti-pattern. This is because of a problem known as double billing. When a function calls another function directly, both run at the same time. The called function is actively running code while the calling function is waiting for a response. In this case, you must pay for the time the calling function spends waiting for the called function to run.
There is no double billing in orchestrator functions. An orchestrator function's billing stops while it waits for the result of an activity function or sub-orchestration.
Durable HTTP polling
Orchestrator functions can make long-running HTTP calls to external endpoints as described in the HTTP features article. The "call HTTP" APIs might internally poll an HTTP endpoint while following the asynchronous 202 pattern.
There currently isn't direct billing for internal HTTP polling operations. However, internal polling might cause the orchestrator function to periodically replay. You'll be billed standard charges for these internal function replays.
Azure Storage transactions
Durable Functions uses Azure Storage by default to keep state persistent, process messages, and manage partitions via blob leases. Because you own this storage account, any transaction costs are billed to your Azure subscription. For more information about the Azure Storage artifacts used by Durable Functions, see the Task hubs article.
Several factors contribute to the actual Azure Storage costs incurred by your Durable Functions app:
- A single function app is associated with a single task hub, which shares a set of Azure Storage resources. These resources are used by all durable functions in a function app. The actual number of functions in the function app has no effect on Azure Storage transaction costs.
- Each function app instance internally polls multiple queues in the storage account by using an exponential-backoff polling algorithm. An idle app instance polls the queues less often than does an active app, which results in fewer transaction costs. For more information about Durable Functions queue-polling behavior when using the Azure Storage provider, see the queue-polling section of the Azure Storage provider documentation.
- When running in the Azure Functions Consumption or Premium plans, the Azure Functions scale controller regularly polls all task-hub queues in the background. If a function app is under light to moderate scale, only a single scale controller instance will poll these queues. If the function app scales out to a large number of instances, more scale controller instances might be added. These additional scale controller instances can increase the total queue-transaction costs.
- Each function app instance competes for a set of blob leases. These instances will periodically make calls to the Azure Blob service either to renew held leases or to attempt to acquire new leases. The task hub's configured partition count determines the number of blob leases. Scaling out to a larger number of function app instances likely increases the Azure Storage transaction costs associated with these lease operations.
You can find more information on Azure Storage pricing in the Azure Storage pricing documentation.