Azure Functions hosting options

Article
05/21/2024

When you create a function app in Azure, you must choose a hosting option for your app. Azure provides you with these hosting options for your function code:

Hosting option	Service	Availability	Container support
Consumption plan	Azure Functions	Generally available (GA)	None
Flex Consumption plan	Azure Functions	Preview	None
Premium plan	Azure Functions	GA	Linux
Dedicated plan	Azure Functions	GA	Linux
Container Apps	Azure Container Apps	GA	Linux

Azure Functions hosting options are facilitated by Azure App Service infrastructure on both Linux and Windows virtual machines. The hosting option you choose dictates the following behaviors:

How your function app is scaled.
The resources available to each function app instance.
Support for advanced functionality, such as Azure Virtual Network connectivity.
Support for Linux containers.

The plan you choose also impacts the costs for running your function code. For more information, see Billing.

This article provides a detailed comparison between the various hosting options. To learn more about running and managing your function code in Linux containers, see Linux container support in Azure Functions.

Overview of plans

The following is a summary of the benefits of the various options for Azure Functions hosting:

Option	Benefits
Consumption plan	Pay for compute resources only when your functions are running (pay-as-you-go) with automatic scale. On the Consumption plan, instances of the Functions host are dynamically added and removed based on the number of incoming events. ✔ Default hosting plan that provides true serverless hosting. ✔ Pay only when your functions are running. ✔ Scales automatically, even during periods of high load.
Flex Consumption plan	Get high scalability with compute choices, virtual networking, and pay-as-you-go billing. On the Flex Consumption plan, instances of the Functions host are dynamically added and removed based on the configured per instance concurrency and the number of incoming events. ✔ Reduce cold starts by specifying a number of pre-provisioned (always ready) instances. ✔ Supports virtual networking for added security. ✔ Pay when your functions are running. ✔ Scales automatically, even during periods of high load.
Premium plan	Automatically scales based on demand using prewarmed workers, which run applications with no delay after being idle, runs on more powerful instances, and connects to virtual networks. Consider the Azure Functions Premium plan in the following situations: ✔ Your function apps run continuously, or nearly continuously. ✔ You want more control of your instances and want to deploy multiple function apps on the same plan with event-driven scaling. ✔ You have a high number of small executions and a high execution bill, but low GB seconds in the Consumption plan. ✔ You need more CPU or memory options than are provided by consumption plans. ✔ Your code needs to run longer than the maximum execution time allowed on the Consumption plan. ✔ You require virtual network connectivity. ✔ You want to provide a custom Linux image in which to run your functions.
Dedicated plan	Run your functions within an App Service plan at regular App Service plan rates. Best for long-running scenarios where Durable Functions can't be used. Consider an App Service plan in the following situations: ✔ You have existing and underutilized virtual machines that are already running other App Service instances. ✔ You must have fully predictable billing, or you need to manually scale instances. ✔ You want to run multiple web apps and function apps on the same plan ✔ You need access to larger compute size choices. ✔ Full compute isolation and secure network access provided by an App Service Environment (ASE). ✔ Very high memory usage and high scale (ASE).
Container Apps	Create and deploy containerized function apps in a fully managed environment hosted by Azure Container Apps. Use the Azure Functions programming model to build event-driven, serverless, cloud native function apps. Run your functions alongside other microservices, APIs, websites, and workflows as container-hosted programs. Consider hosting your functions on Container Apps in the following situations: ✔ You want to package custom libraries with your function code to support line-of-business apps. ✔ You need to migration code execution from on-premises or legacy apps to cloud native microservices running in containers. ✔ When you want to avoid the overhead and complexity of managing Kubernetes clusters and dedicated compute. ✔ Your functions need high-end processing power provided by dedicated GPU compute resources.

The remaining tables in this article compare hosting options based on various features and behaviors.

Operating system support

This table shows operating system support for the hosting options.

Hosting	Linux¹ deployment	Windows² deployment
Consumption plan	✅ Code-only ❌ Container (not supported)	✅ Code-only
Flex Consumption plan	✅ Code-only ❌ Container (not supported)	❌ Not supported
Premium plan	✅ Code-only ✅ Container	✅ Code-only
Dedicated plan	✅ Code-only ✅ Container	✅ Code-only
Container Apps	✅ Container-only	❌ Not supported

¹ Linux is the only supported operating system for the Python runtime stack.
² Windows deployments are code-only. Functions doesn't currently support Windows containers.

Function app timeout duration

The timeout duration for functions in a function app is defined by the functionTimeout property in the host.json project file. This property applies specifically to function executions. After the trigger starts function execution, the function needs to return/respond within the timeout duration. For more information, see Improve Azure Functions performance and reliability.

The following table shows the default and maximum values (in minutes) for specific plans:

Plan	Default	Maximum¹
Consumption plan	5	10
Flex Consumption plan	30	Unlimited³
Premium plan	30²	Unlimited³
Dedicated plan	30²	Unlimited³

¹ Regardless of the function app timeout setting, 230 seconds is the maximum amount of time that an HTTP triggered function can take to respond to a request. This is because of the default idle timeout of Azure Load Balancer. For longer processing times, consider using the Durable Functions async pattern or defer the actual work and return an immediate response.
² The default timeout for version 1.x of the Functions runtime is unlimited.
³ Guaranteed for up to 60 minutes. OS and runtime patching, vulnerability patching, and scale in behaviors can still cancel function executions so ensure to write robust functions. ⁴ In a Flex Consumption plan, the host doesn't enforce an execution time limit. However, there are currently no guarantees because the platform might need to terminate your instances during scale-in, deployments, or to apply updates.

Language support

For details on current native language stack support in Functions, see Supported languages in Azure Functions.

Scale

The following table compares the scaling behaviors of the various hosting plans.
Maximum instances are given on a per-function app (Consumption) or per-plan (Premium/Dedicated) basis, unless otherwise indicated.

Plan	Scale out	Max # instances
Consumption plan	Event driven. Scales out automatically, even during periods of high load. Functions infrastructure scales CPU and memory resources by adding more instances of the Functions host, based on the number of incoming trigger events.	Windows: 200 Linux: 100¹
Flex Consumption plan	Per-function scaling. Event-driven scaling decisions are calculated on a per-function basis, which provides a more deterministic way of scaling the functions in your app. With the exception of HTTP, Blob storage (Event Grid), and Durable Functions, all other function trigger types in your app scale on independent instances. All HTTP triggers in your app scale together as a group on the same instances, as do all Blob storage (Event Grid) triggers. All Durable Functions triggers also share instances and scale together.	Limited only by total memory usage of all instances across a given region. For more information, see Instance memory.
Premium plan	Event driven. Scale out automatically, even during periods of high load. Azure Functions infrastructure scales CPU and memory resources by adding more instances of the Functions host, based on the number of events that its functions are triggered on.	Windows: 100 Linux: 20-100²
Dedicated plan³	Manual/autoscale	10-30 100 (ASE)

¹ During scale-out, there's currently a limit of 500 instances per subscription per hour for Linux apps on a Consumption plan.
² In some regions, Linux apps on a Premium plan can scale to 100 instances. For more information, see the Premium plan article.
³ For specific limits for the various App Service plan options, see the App Service plan limits.

Cold start behavior

Plan	Details
Consumption plan	Apps can scale to zero when idle, meaning some requests might have more latency at startup. The consumption plan does have some optimizations to help decrease cold start time, including pulling from prewarmed placeholder functions that already have the function host and language processes running.
Flex Consumption plan	Supports always ready instances to reduce the delay when provisioning new instances.
Premium plan	Supports always ready instances to avoid cold starts by letting you maintain one or more perpetually warm instances.
Dedicated plan	When running in a Dedicated plan, the Functions host can run continuously on a prescribed number of instances, which means that cold start isn't really an issue.

Service limits

Resource	Consumption plan	Flex Consumption plan¹²	Premium plan	Dedicated plan/ASE
Default timeout duration (min)	5	30	30	30¹
Max timeout duration (min)	10	unbounded¹⁵	unbounded⁷	unbounded²
Max outbound connections (per instance)	600 active (1200 total)	unbounded	unbounded	unbounded
Max request size (MB)³	100	100	100	100
Max query string length³	4096	4096	4096	4096
Max request URL length³	8192	8192	8192	8192
ACU per instance	100	varies	210-840	100-840/210-250⁸
Max memory (GB per instance)	1.5	4¹³	3.5-14	1.75-14/3.5-14
Max instance count (Windows/Linux)	200/100	1000 ¹⁴	100/20	varies by SKU/100⁹
Function apps per plan¹¹	100	100	100	unbounded⁴
App Service plans	100 per region	n/a	100 per resource group	100 per resource group
Deployment slots per app¹⁰	2	n/a	3	1-20⁹
Storage⁵	5 GB	250 GB	250 GB	50-1000 GB
Custom domains per app	500⁶	500	500	500
Custom domain SSL support	unbounded SNI SSL connection included	unbounded SNI SSL and 1 IP SSL connections included	unbounded SNI SSL and 1 IP SSL connections included	unbounded SNI SSL and 1 IP SSL connections included

Notes on service limits:

By default, the timeout for the Functions 1.x runtime in an App Service plan is unbounded.
Requires the App Service plan be set to Always On. Pay at standard rates.
These limits are set in the host.
The actual number of function apps that you can host depends on the activity of the apps, the size of the machine instances, and the corresponding resource utilization.
The storage limit is the total content size in temporary storage across all apps in the same App Service plan. Consumption plan uses Azure Files for temporary storage.
When your function app is hosted in a Consumption plan, only the CNAME option is supported. For function apps in a Premium plan or an App Service plan, you can map a custom domain using either a CNAME or an A record.
Guaranteed for up to 60 minutes.
Workers are roles that host customer apps. Workers are available in three fixed sizes: One vCPU/3.5 GB RAM; Two vCPU/7 GB RAM; Four vCPU/14 GB RAM.
See App Service limits for details.
Including the production slot.
There's currently a limit of 5000 function apps in a given subscription.
The Flex Consumption plan is currently in preview.
Flex Consumption plan instance sizes are currently defined as either 2,048 MB or 4,096 MB. For more information, see Instance memory.
Flex Consumption plan during preview has a regional subscription quota that limits the total memory usage of all instances across a given region. For more information, see Instance memory.
In a Flex Consumption plan, the host doesn't enforce an execution time limit. However, there are currently no guarantees because the platform might need to terminate your instances during scale-in, deployments, or to apply updates.

Networking features

Feature	Consumption plan	Flex Consumption plan	Premium plan	Dedicated plan/ASE
Inbound IP restrictions	✅Yes	✅Yes	✅Yes	✅Yes
Inbound Private Endpoints	❌No	✅Yes	✅Yes	✅Yes
Virtual network integration	❌No	✅Yes (Regional)	✅Yes (Regional)	✅Yes (Regional and Gateway)
Virtual network triggers (non-HTTP)	❌No	✅Yes	✅Yes	✅Yes
Hybrid connections (Windows only)	❌No	✅Yes	✅Yes	✅Yes
Outbound IP restrictions	❌No	✅Yes	✅Yes	✅Yes

Billing

Plan	Details
Consumption plan	Pay only for the time your functions run. Billing is based on number of executions, execution time, and memory used.
Flex Consumption plan	Billing is based on number of executions, the memory of instances when they're actively executing functions, plus the cost of any always ready instances. For more information, see Flex Consumption plan billing.
Premium plan	Premium plan is based on the number of core seconds and memory used across needed and prewarmed instances. At least one instance per plan must always be kept warm. This plan provides the most predictable pricing.
Dedicated plan	You pay the same for function apps in an App Service Plan as you would for other App Service resources, like web apps. For an ASE, there's a flat monthly rate that pays for the infrastructure and doesn't change with the size of the environment. There's also a cost per App Service plan vCPU. All apps hosted in an ASE are in the Isolated pricing SKU. For more information, see the ASE overview article.

For a direct cost comparison between dynamic hosting plans (Consumption, Flex Consumption, and Premium), see the Azure Functions pricing page. For pricing of the various Dedicated plan options, see the App Service pricing page. For pricing Container Apps hosting, see Azure Container Apps pricing.

Limitations for creating new function apps in an existing resource group

In some cases, when trying to create a new hosting plan for your function app in an existing resource group you might receive one of the following errors:

The pricing tier is not allowed in this resource group
<SKU_name> workers are not available in resource group <resource_group_name>

This can happen when the following conditions are met:

You create a function app in an existing resource group that has ever contained another function app or web app. For example, Linux Consumption apps aren't supported in the same resource group as Linux Dedicated or Linux Premium plans.
Your new function app is created in the same region as the previous app.
The previous app is in some way incompatible with your new app. This error can happen between SKUs, operating systems, or due to other platform-level features, such as availability zone support.

The reason this happens is due to how function app and web app plans are mapped to different pools of resources when being created. Different SKUs require a different set of infrastructure capabilities. When you create an app in a resource group, that resource group is mapped and assigned to a specific pool of resources. If you try to create another plan in that resource group and the mapped pool does not have the required resources, this error occurs.

When this error occurs, instead create your function app and hosting plan in a new resource group.

Share via