Proposed Pull Request Change

📄 Document Links

View on GitHub View on Microsoft Learn

--- title: Azure Functions Premium plan description: Learn about details and configuration options (virtual network, no cold start, unlimited execution duration) for the Azure Functions Premium plan. author: nzthiago ms.topic: concept-article ms.date: 12/15/2025 ms.author: thalme ms.custom: references_regions, fasttrack-edit, devx-track-azurepowershell, build-2024 --- # Azure Functions Premium plan The Azure Functions Elastic Premium plan is a dynamic scale hosting option for function apps. For other hosting plan options, see [Azure Functions hosting options](functions-scale.md). [!INCLUDE [functions-premium-plan-note](../../includes/functions-premium-plan-note.md)] Premium plan hosting provides the following benefits for your functions: * *Always ready* and *prewarmed* instances to avoid cold starts * Virtual network connectivity * Support for [longer runtime durations](#longer-run-duration) * [Choice of Premium instance sizes](#available-instance-skus) * More predictable pricing, compared with the Consumption plan * High-density app allocation for plans with multiple function apps * Support for [Linux container deployments](./container-concepts.md) When you use the Premium plan, you add and remove instances of the Azure Functions host based on the number of incoming events, just like the [Flex Consumption plan](./flex-consumption-plan.md) and the [Consumption plan](consumption-plan.md). You can deploy multiple function apps to the same Premium plan. You can configure the compute instance size, base plan size, and maximum plan size. ## Billing You pay for the Premium plan based on the number of core seconds and memory allocated across instances. This billing model differs from the Consumption plan, which bills you based on per-second resource consumption and executions. The Premium plan has no execution charge. This billing model results in a minimum monthly cost per active plan, whether the function is active or idle. All function apps in a Premium plan share allocated instances. For more information, see [Azure Functions pricing](https://azure.microsoft.com/pricing/details/functions/). > [!NOTE] > Every premium plan always has at least one active (billed) instance. ## Create a Premium plan When you create a function app in the Azure portal, the Consumption plan is the default. To create a function app that runs in a Premium plan, you must explicitly create or choose an Azure Functions Premium hosting plan by using one of the _Elastic Premium_ versions. You host the function app you create in this plan. The Azure portal makes it easy to create both the Premium plan and the function app at the same time. You can run more than one function app in the same Premium plan, but they must both run on the same operating system (Windows or Linux). The following articles show you how to programmatically create a function app with a Premium plan: + [Azure CLI](scripts/functions-cli-create-premium-plan.md) + [Azure Resource Manager template](functions-infrastructure-as-code.md?pivots=premium-plan) ## Eliminate cold starts When events or executions don't occur in the Consumption plan, your app might scale to zero instances. When new events arrive, the system must create a new instance that runs your app. Specializing new instances takes time, depending on the app. This extra latency on the first call is often called a [cold start](./event-driven-scaling.md#cold-start). The Premium plan provides two features that work together to effectively eliminate cold starts in your functions: _always ready instances_ and _prewarmed instances_. Always ready instances are a category of preallocated instances unaffected by scaling, and the prewarmed instances are a buffer as you scale due to HTTP events. When events begin to trigger the app, the system first routes them to the always ready instances. As the function becomes active due to HTTP events, other instances warm as a buffer. These buffered instances are called prewarmed instances. This buffer reduces cold start for new instances required during scale. ### Always ready instances In the Premium plan, you can have your app always ready on a specified number of instances. Your app runs continuously on those instances, regardless of load. If load exceeds what your always ready instances can handle, the app adds more instances as necessary, up to your specified maximum. This app-level setting also controls your plan's minimum instances. For example, consider three function apps in the same Premium plan. When two of your apps have always ready instance count set to one, and the third app is set to five, the minimum number for your whole plan is five. This number also reflects the minimum number of instances for which your plan is billed. The maximum number of always ready instances supported per app is 20. #### [Portal](#tab/portal) You can configure the number of always ready instances in the Azure portal by selecting your **Function App**, going to the **App Service plan** > **Scale Out** menu option on the left, and editing the **App Scale out** options. In the function app edit window, always ready instances are specific to that app. #### [Azure CLI](#tab/azurecli) You can also configure always ready instances for an app by using the Azure CLI. ```azurecli-interactive az functionapp update -g <RESOURCE_GROUP> -n <FUNCTION_APP_NAME> --set siteConfig.minimumElasticInstanceCount=<YOUR_ALWAYS_READY_COUNT> ``` #### [Azure PowerShell](#tab/azure-powershell) You can also configure always ready instances for an app by using Azure PowerShell. ```azurepowershell-interactive $Resource = Get-AzResource -ResourceGroupName <RESOURCE_GROUP> -ResourceName <FUNCTION_APP_NAME>/config/web -ResourceType Microsoft.Web/sites $Resource.Properties.minimumElasticInstanceCount = <YOUR_ALWAYS_READY_COUNT> $Resource | Set-AzResource -Force ``` --- ### Prewarmed instances The prewarmed instance count setting provides warmed instances as a buffer during HTTP scale and activation events. Prewarmed instances continue to buffer until the maximum scale-out limit is reached. The default prewarmed instance count is 1 and, for most scenarios, keep this value as 1. Consider a less common scenario, such as an app running in a custom container. Because custom containers have a long warm-up time, you might consider increasing this buffer of prewarmed instances. A prewarmed instance becomes active only after all active instances are in use. You can also define a warmup trigger that runs during the prewarming process. You can use a warmup trigger to preload custom dependencies during the prewarming process so your functions are ready to start processing requests immediately. To learn more, see [Azure Functions warmup trigger](functions-bindings-warmup.md). Consider this example that shows how always ready instances and prewarmed instances work together. A premium function app has two always ready instances configured, and the default of one prewarmed instance. :::image type="content" source="media/functions-premium-plan/scale-graph.png" alt-text="Screenshot showing the scale-out graph."::: 1. When the app is idle and no events are triggering, the app is provisioned and running with two instances. At this time, you're billed for the two always ready instances but aren't billed for a prewarmed instance because no prewarmed instance is allocated. 1. As your application starts receiving HTTP traffic, requests are load balanced across the two always ready instances. As soon as those two instances start processing events, an instance is added to fill the prewarmed buffer. The app is now running with three provisioned instances: the two always ready instances, and the third prewarmed and inactive buffer. You're billed for the three instances. 1. As load increases and your app needs more instances to handle HTTP traffic, that prewarmed instance swaps to an active instance. HTTP load is now routed to all three instances, and a fourth instance is instantly provisioned to fill the prewarmed buffer. 1. This sequence of scaling and prewarming continues until the maximum instance count for the app is reached or load decreases causing the platform to scale back in after a period. No instances are prewarmed or activated beyond the maximum. #### [Portal](#tab/portal) You can't change the prewarmed instance count setting in the portal. You must instead use the Azure CLI or Azure PowerShell. #### [Azure CLI](#tab/azurecli) You can modify the number of prewarmed instances for an app by using the Azure CLI. ```azurecli-interactive az functionapp update -g <RESOURCE_GROUP> -n <FUNCTION_APP_NAME> --set siteConfig.preWarmedInstanceCount=<YOUR_PREWARMED_COUNT> ``` #### [Azure PowerShell](#tab/azure-powershell) You can modify the number of prewarmed instances for an app by using the Azure PowerShell. ```azurepowershell-interactive $Resource = Get-AzResource -ResourceGroupName <RESOURCE_GROUP> -ResourceName <FUNCTION_APP_NAME>/config/web -ResourceType Microsoft.Web/sites $Resource.Properties.preWarmedInstanceCount = <YOUR_PREWARMED_COUNT> $Resource | Set-AzResource -Force ``` --- ### Maximum function app instances In addition to the [plan maximum burst count](#plan-and-sku-settings), you can configure a per-app maximum. You configure the app maximum by using the [app scale limit](./event-driven-scaling.md#limit-scale-out). The maximum app scale-out limit can't exceed the maximum burst instances of the plan. ## Private network connectivity Function apps deployed to a Premium plan can take advantage of [virtual network integration for web apps](../app-service/overview-vnet-integration.md). When configured, your app can communicate with resources within your virtual network or secured via service endpoints. You can also use IP restrictions on the app to restrict incoming traffic. When assigning a subnet to your function app in a Premium plan, you need a subnet with enough IP addresses for each potential instance. You need an IP block with at least 100 available addresses. For more information, see [Integrate Azure Functions with a virtual network](functions-create-vnet.md). ## Rapid elastic scale The same rapid scaling logic as the Flex Consumption and Consumption plans automatically adds more compute instances for your app. Apps in the same App Service Plan scale independently from one another based on the needs of an individual app. However, Functions apps in the same App Service Plan share VM resources to help reduce costs, when possible. The number of apps associated with a VM depends on the footprint of each app and the size of the VM. To learn more about how scaling works, see [Event-driven scaling in Azure Functions](event-driven-scaling.md). ## Longer run duration Functions in a Consumption plan are limited to 10 minutes for a single execution. In the Premium plan, the run duration defaults to 30 minutes to prevent runaway executions. However, you can [modify the host.json configuration](./functions-host-json.md#functiontimeout) to make the duration unbounded for Premium plan apps, with the following limitations: + Platform upgrades can trigger a managed shutdown and halt the function execution with a grace period of 10 minutes. + An idle timer stops the worker after 60 minutes with no new executions. + [Scale-in behavior](event-driven-scaling.md#scale-in-behaviors) can cause worker shutdown after 60 minutes. + [Slot swaps](functions-deployment-slots.md) can terminate executions on the source and target slots during the swap. ## Migration If you have an existing function app, you can use Azure CLI commands to migrate your app between a Consumption plan and a Premium plan on Windows. The specific commands depend on the direction of the migration. For more information, see [Plan migration](functions-how-to-use-azure-function-app-settings.md#plan-migration). This migration isn't supported on Linux. ## <a name="plan-and-sku-settings"></a>Premium plan settings When you create the plan, you set two plan size settings: the minimum number of instances (or plan size) and the maximum burst limit. If your app needs more instances beyond the always ready instances, it can continue to scale out until the number of instances reaches the plan maximum burst limit, or the app maximum scale-out limit if you set it. You pay for instances only while they're running and allocated to you, on a per-second basis. The platform makes its best effort at scaling your app out to the defined maximum limits. ### [Portal](#tab/portal) You can configure the plan size in the Azure portal by selecting your **Function App** deployed to that plan, going to the **App Service plan** > **Scale Up** menu options on the left, and choosing a larger plan size. To increase the maximum burst limit, choose the **Scale Out** menu option and edit the **Plan Scale out** > **Maximum burst** option. ### [Azure CLI](#tab/azurecli) Use Azure CLI to increase the maximum burst limit: ```azurecli-interactive az functionapp plan update -g <RESOURCE_GROUP> -n <PREMIUM_PLAN_NAME> --max-burst <YOUR_MAX_BURST> ``` ### [Azure PowerShell](#tab/azure-powershell) You can also increase the maximum burst limit by using Azure PowerShell: ```azurepowershell-interactive Update-AzFunctionAppPlan -ResourceGroupName <RESOURCE_GROUP> -Name <PREMIUM_PLAN_NAME> -MaximumWorkerCount <YOUR_MAX_BURST> -Force ``` --- The minimum for every Premium plan is at least one instance. The actual minimum number of instances is determined based on the always ready instances requested by apps in the plan. For example, if app A requests five always ready instances, and app B requests two always ready instances in the same plan, the minimum plan size is determined as five. App A runs on all five instances, and app B runs on two. > [!IMPORTANT] > You're charged for each instance allocated in the minimum instance count whether or not functions are executing. In most circumstances, this autocalculated minimum is sufficient. However, scaling beyond the minimum occurs at a best effort. It's possible, though unlikely, that at a specific time scale-out could be delayed if other instances are unavailable. By setting a minimum higher than the autocalculated minimum, you reserve instances in advance of scale-out. ### [Portal](#tab/portal) You can configure the minimum instances in the Azure portal by selecting your **Function App** deployed to that plan, going to the **App Service plan** > **Scale Out** menu option on the left, and editing the **Plan Scale out** > **Minimum Instances** option. ### [Azure CLI](#tab/azurecli) Increase the calculated minimum for a plan by using Azure CLI. ```azurecli-interactive az functionapp plan update -g <RESOURCE_GROUP> -n <PREMIUM_PLAN_NAME> --min-instances <YOUR_MIN_INSTANCES> ``` ### [Azure PowerShell](#tab/azure-powershell) Increase the calculated minimum for a plan by using Azure PowerShell. ```azurepowershell-interactive Update-AzFunctionAppPlan -ResourceGroupName <RESOURCE_GROUP> -Name <PREMIUM_PLAN_NAME> -MinimumWorkerCount <YOUR_MIN_INSTANCES> -Force ``` --- ### Available instance SKUs When you create or scale your plan, choose from three instance sizes. You're billed for the total number of cores and memory you provision, per second for each instance allocated to you. Your app can automatically scale out to multiple instances as needed. |SKU|Cores|Memory|Storage| |--|--|--|--| |EP1|1|3.5 GB|250 GB| |EP2|2|7 GB|250 GB| |EP3|4|14 GB|250 GB| ### Memory usage considerations Running on a machine with more memory doesn't always mean that your function app uses all available memory. For example, a JavaScript function app is constrained by the default memory limit in Node.js. To increase this fixed memory limit, add the app setting `languageWorkers:node:arguments` with a value of `--max-old-space-size=<max memory in MB>`. For plans with more than 4 GB of memory, set the Bitness Platform Setting to `64 Bit` under [General settings](../app-service/configure-common.md#configure-general-settings). ## Region max scale-out The following table lists currently supported maximum scale-out values for a single plan in each region and OS configuration: |Region| Windows | Linux | |--| -- | -- | |Australia Central| 100 | 20 | |Australia Central 2| 100 | Not Available | |Australia East| 100 | 40 | |Australia Southeast | 100 | 20 | |Brazil South| 100 | 20 | |Canada Central| 100 | 100 | |Central India| 100 | 20 | |Central US| 100 | 100 | |China East 2| 20 | 20 | |China North 2| 20 | 20 | |China North 3| 20 | 20 | |East Asia| 100 | 20 | |East US | 100 | 100 | |East US 2| 80 | 100 | |France Central| 100 | 60 | |Germany West Central| 100 | 20 | |Israel Central| 100 | 20 | |Italy North | 100 | 20 | |Japan East| 100 | 20 | |Japan West| 100 | 20 | |Jio India West| 100 | 20 | |Korea Central| 100 | 20 | |Korea South| 40 | 20 | |Mexico Central| 20 | 20 | |North Central US| 100 | 20 | |North Europe| 100 | 100 | |Norway East| 100 | 20 | |South Africa North| 100 | 20 | |South Africa West| 20 | 20 | |South Central US| 100 | 100 | |South India | 100 | Not Available | |Southeast Asia| 100 | 20 | |Spain Central| 20 | 20 | |Switzerland North| 100 | 20 | |Switzerland West| 100 | 20 | |UAE North| 100 | 100 | |UK South| 100 | 100 | |UK West| 100 | 20 | |USGov Arizona| 20 | 20 | |USGov Texas| 20 | Not Available | |USGov Virginia| 80 | 20 | |West Central US| 100 | 20 | |West Europe| 100 | 100 | |West India| 100 | 20 | |West US| 100 | 100 | |West US 2| 100 | 20 | |West US 3| 100 | 20 | For more information, see [Products available by region](https://azure.microsoft.com/global-infrastructure/services/?products=functions). ## Related content * [Understand Azure Functions hosting options](functions-scale.md) * [Event-driven scaling in Azure Functions](event-driven-scaling.md)