Choose the right Azure Functions plan

An Azure Functions hosting plan determines how an app scales and how compute is billed. It also affects network features, runtime options, and execution limits.

The available plans have changed since this article first appeared in 2021. Microsoft now identifies Flex Consumption as the serverless plan for new function apps, while the earlier Consumption plan is a legacy option.

Compare the current hosting options

Flex Consumption

Flex Consumption supports event-driven scaling, selectable memory sizes, virtual-network integration, and optional always-ready instances.

Consider it for variable workloads that should scale toward zero but still need current serverless networking and scaling features. Always-ready instances change the cold-start and cost profile, so test the chosen configuration.

Premium

Premium uses prewarmed workers and supports features needed by workloads that cannot tolerate a cold start or require broader networking and compute choices.

It can suit sustained or bursty applications with stricter latency requirements. Billing continues for allocated baseline instances, so include that baseline in the cost model.

Dedicated App Service plan

A Dedicated plan runs functions on allocated App Service compute. It can share a plan with other apps and offers predictable resources, but the team pays for the plan while it is allocated.

Use it when existing App Service capacity, manual scaling, or a dedicated operating model matters more than scale-to-zero behaviour.

Azure Container Apps

Container Apps can host code that uses the Azure Functions programming model in a managed container environment.

It fits teams that need control of the container image, custom libraries, or placement beside other containerized services without operating Kubernetes directly.

Consumption

The original Consumption plan remains relevant to some existing Windows function apps. Microsoft classifies it as a legacy hosting plan and directs new serverless apps toward Flex Consumption.

Do not treat its historical free grant, limits, or timeout values as current without checking the pricing and hosting documentation.

Match the plan to the workload

Ask these questions before choosing:

• Which triggers and languages does the app use?
• How quickly must the first request respond after an idle period?
• Does the app need private network access?
• What memory, CPU, and execution duration does each event need?
• Is demand steady, intermittent, or sharply bursty?
• Does the team need a custom container?
• Which dependencies must be available in every region?
• What monitoring and recovery does the operation require?

A plan comparison without the workload shape usually produces a pricing guess rather than an architecture decision.

Include the surrounding resources

A function app normally depends on storage, monitoring, network, identity, and downstream services. Those resources have their own costs and limits.

Model Application Insights ingestion and retention, storage transactions, outbound data, private networking, always-ready instances, and dependent services alongside function execution.

Test scale and failure behaviour

Load tests should include realistic concurrency, message size, dependency latency, and retry behaviour. Confirm what happens when the downstream service throttles or the function exceeds its time boundary.

For queue or event processing, make operations idempotent so a retry does not create a duplicate business action.

Use the maintained comparison

Microsoft’s Azure Functions hosting options page compares current availability, operating systems, container support, timeouts, networking, scale, and billing.

Use that source with current Azure Functions pricing for the target region. Then validate the chosen plan with a representative deployment rather than relying on a generic plan label.