Proposed Pull Request Change

📄 Document Links

View on GitHub View on Microsoft Learn

--- title: Azure Functions Scale and Hosting description: Compare the various options you need to consider when choosing a hosting plan in which to run your function app in Azure Functions. ms.assetid: 5b63649c-ec7f-4564-b168-e0a74cb7e0f3 ms.topic: limits-and-quotas ms.date: 12/09/2025 ms.custom: H1Hack27Feb2017, devdivchpfy22, build-2023, build-2024, ignite-2024 #customer intent: As a cloud developer or platform engineer, I want guidance on Functions scaling and hosting so I can choose the best hosting plan for performance and cost-efficiency when running my code in Azure. --- # Azure Functions hosting options 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 | | --- | --- | --- | --- | | **[Flex Consumption plan]** | Azure Functions | Generally available (GA) | None | | **[Premium plan]** | Azure Functions | GA | Linux | | **[Dedicated plan]** | Azure Functions | GA | Linux | | **[Container Apps]** | Azure Container Apps | GA | Linux | | **[Consumption plan]** | Azure Functions | Windows - GA<br/>Linux - Retired | None | [!INCLUDE [functions-linux-consumption-retirement](../../includes/functions-linux-consumption-retirement.md)] The Azure App Service infrastructure on both Linux and Windows virtual machines facilitates the Azure Functions hosting options. 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](#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](container-concepts.md). ## Overview of plans The following table summarizes the benefits of the various options for Azure functions hosting. | Option | Benefits | | --- | --- | |**[Flex Consumption plan]**|Experience fast horizontal scaling, with flexible compute options, virtual network integration, and serverless pay-as-you-go billing.<br/><br/>In the Flex Consumption plan, function instances dynamically scale out (up to 1,000) based on configured per-instance concurrency, incoming events, and per-function workloads for optimal efficiency.<br/><br/>Consider the Flex Consumption plan when:<br/><br/>✔ You need a serverless host for your function code, paying only for on-demand executions.<br/>✔ You require virtual network connectivity for secure access to Azure resources.<br/>✔ Your workloads are variable and can go from no activity to demanding rapid, event-driven scaling.<br/>✔ You want to customize compute with memory sizes (512 MB, 2,048 MB, or 4,096 MB) and reduce cold starts via one or more pre-provisioned (always-ready) instances.| |**[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. <br/><br/>Consider the Azure Functions Premium plan in the following situations: <br/><br/>✔ Your function apps run continuously, or nearly continuously.<br/>✔ You want more control of your instances and want to deploy multiple function apps on the same plan with event-driven scaling.<br/>✔ You have a high number of small executions and a high execution bill, but low GB seconds in the Consumption plan.<br/>✔ You need more CPU or memory options than are provided by consumption plans.<br/>✔ Your code needs to run longer than the maximum execution time allowed on the Consumption plan.<br/>✔ You require virtual network connectivity for secure access to Azure resources.<br/>✔ 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](https://azure.microsoft.com/pricing/details/app-service/windows/).<br/><br/>Best for long-running scenarios where [Durable Functions](durable/durable-functions-overview.md) can't be used. Consider an App Service plan in the following situations:<br/><br/>✔ You have existing and underutilized virtual machines that are already running other App Service instances.<br/>✔ You must have fully predictable billing, or you need to manually scale instances.<br/>✔ You want to run multiple web apps and function apps on the same plan<br/>✔ You need access to larger compute size choices.<br/>✔ Full compute isolation and secure network access provided by an App Service Environment (ASE).<br/>✔ 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.<br/><br/>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:<br/><br/>✔ You want control of the container image and want to package custom libraries with your function code to support line-of-business apps.<br/>✔ You need to migrate code execution from on-premises or legacy apps to cloud native microservices running in containers.<br/>✔ When you want to avoid the overhead and complexity of managing Kubernetes clusters and dedicated compute.<br/>✔ Your functions need high-end processing power provided by dedicated GPU compute resources. | |**[Consumption plan]**| Pay for compute resources only when your functions are running (pay-as-you-go) with automatic scale on Windows.<br/><br/>On the Consumption plan, function instances are dynamically added and removed based on the number of incoming events.<br/><br/>Consider the Consumption plan when:<br/><br/>✔ You have a dependency on Windows. For example, using the v1 runtime, the full .NET Framework, or Windows-specific features like certain PowerShell modules.<br/>✔ You want a serverless billing model and pay only when your functions are running.| The remaining tables in this article compare hosting options based on various features and behaviors. ## <a name="operating-systemruntime"></a>Operating system support This table shows operating system support for the hosting options. | Hosting | Linux¹ deployment| Windows² deployment | | --- | --- | --- | | **[Flex Consumption plan]** | ✅ Code-only<br/>❌ Container (not supported) | ❌ Not supported | | **[Premium plan]** | ✅ Code-only<br/>✅ Container | ✅ Code-only | | **[Dedicated plan]** | ✅ Code-only<br/>✅ Container | ✅ Code-only | | **[Container Apps]** | ✅ Container-only | ❌ Not supported | | **[Consumption plan]**³ | ✅ Code-only (Retired)<br/>❌ Container (not supported) | ✅ Code-only | 1. Linux is the only supported operating system for the [Python runtime stack](./functions-reference-python.md). 2. Windows deployments are code-only. Azure Functions doesn't currently support Windows containers. 3. The ability to run your app on Linux in a Consumption plan will be retired on 30 September 2028. For more information, see [Consumption plan]. [!INCLUDE [Timeout Duration section](../../includes/functions-timeout-duration.md)] ## Language support For details on current native language stack support in Functions, see [Supported languages in Azure Functions](supported-languages.md). ## 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 | | --- | --- | --- | | **[Flex Consumption plan]** | Fast event-driven scaling decisions are calculated on a per-function basis, called [per-function scaling](./flex-consumption-plan.md#per-function-scaling), which provides a more deterministic way of scaling the functions in your app. Except for 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. | 1000¹ | | **[Premium plan]** | [Event driven](event-driven-scaling.md). 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⁶<br/>**Linux:** 20-100^2,6| | **[Dedicated plan]** | Manual/autoscale |10-30³<br/>100 (ASE)| | **[Container Apps]** | [Event driven](event-driven-scaling.md). 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. | 300-1000⁴ | | **[Consumption plan]** | [Event driven](event-driven-scaling.md). Automatic scale based on the source of events. Functions infrastructure scales resources by adding more instances of the function host, based on the number of incoming trigger events. | **Windows:** 200<br/>**Linux:** 100⁵ | 1. Flex Consumption plan has a regional subscription quota that limits the total memory usage of all instances across a given region. For more information, see [Regional subscription memory quotas](flex-consumption-plan.md#regional-subscription-memory-quotas). Flex Consumption plans currently only support Linux. 2. In some regions, Linux apps on a Premium plan can scale to 100 instances. For more information, see the [Premium plan article](functions-premium-plan.md#region-max-scale-out). 3. For specific limits for the various App Service plan options, see the [App Service plan limits](../azure-resource-manager/management/azure-subscription-service-limits.md#azure-app-service-limits). 4. On Container Apps, the default is 10 instances, but you can set the [maximum number of replicas](../container-apps/scale-app.md#scale-definition), which has an overall maximum of 1000. This setting is honored as long as there's enough cores quota available. For more information, see [Quotas for Azure Container Apps](/azure/container-apps/quotas). When you create your function app from the Azure portal, you're limited to 300 instances. 5. During scale-out, there's currently a limit of 500 instances per subscription per hour for Linux apps on a Consumption plan. 6. For private endpoint restricted http triggers, scaling out is limited to at most 20 instances. ## Cold start behavior | Plan | Details | | ---- | ---- | | **[Flex Consumption plan]** | Improved cold start even when scaled to zero. Supports [always ready instances](./flex-consumption-plan.md#always-ready-instances) to further reduce the delay when provisioning new instances. | | **[Premium plan]** | Supports [always ready instances](./functions-premium-plan.md#always-ready-instances) to avoid cold starts by letting you maintain one or more _perpetually warm_ instances. | | **[Dedicated plan]** | When it runs 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. | | **[Container Apps]** | Depends on the [minimum number of replicas](../container-apps/scale-app.md#scale-definition):<br/> • When set to zero: apps can scale to zero when idle and some requests might have more latencies at startup.<br/>• When set to one or more: the host process runs continuously, which means that cold start isn't an issue. | | **[Consumption plan]** | Apps can scale to zero when idle, meaning some requests might have more latencies 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 host and language processes running. | ## Service limits [!INCLUDE [functions-limits](../../includes/functions-limits.md)] ## Networking features [!INCLUDE [functions-networking-features](../../includes/functions-networking-features.md)] ## Billing | Plan | Details | | --- | --- | | **[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](./flex-consumption-plan.md#always-ready-instances). For more information, see [Flex Consumption plan billing](flex-consumption-plan.md#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.<br/><br/>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 model. For more information, see the [ASE overview article](../app-service/environment/overview.md#pricing). | | **[Container Apps]** | Billing in Azure Container Apps is based on your plan type. For more information, see [Billing in Azure Container Apps](../container-apps/billing.md).| | **[Consumption plan]** | Pay only for the time your functions run. Billing is based on number of executions, execution time, and memory used. | For a direct cost comparison between dynamic hosting plans (Consumption, Flex Consumption, and Premium), see the [Azure Functions pricing page](https://azure.microsoft.com/pricing/details/functions/). For pricing of the various Dedicated plan options, see the [App Service pricing page](https://azure.microsoft.com/pricing/details/app-service). For pricing Container Apps hosting, see [Azure Container Apps pricing](https://azure.microsoft.com/pricing/details/container-apps/). <!---this needs to move into a troubleshooting how to article--> ## 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 isn't allowed in this resource group - <SKU_name> workers aren't available in resource group <resource_group_name> These errors can occur when the following conditions are met: - You create a function app in an existing resource group that has yet to contain 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 incompatibility can occur between versions, operating systems, or is due to other platform-level features, such as availability zone support. Function app and web app plans are mapped to different pools of resources when they're created. Different plans 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 doesn't have the required resources, the previously mentioned errors occur. If this situation happens, create your function app and hosting plan in a new resource group instead. ## Next steps + [Deployment technologies in Azure Functions](functions-deployment-technologies.md) + [Azure Functions developer guide](functions-reference.md) [Consumption plan]: consumption-plan.md [Flex Consumption plan]: flex-consumption-plan.md [Premium plan]: functions-premium-plan.md [Dedicated plan]: dedicated-plan.md [Container Apps]: ../container-apps/functions-overview.md