Document Details

Functions Premium Plan
Home / Scan #48 / Functions Premium Plan
Sad Tux - Windows bias detected
This page contains Windows bias

About This Page

This page is part of the Azure documentation. It contains code examples and configuration instructions for working with Azure services.
GitHub View on GitHub 📚 View on Microsoft Learn

Bias Analysis

Detected Bias Types
windows_first
powershell_heavy
windows_tools
missing_linux_example
Summary
The documentation demonstrates several forms of Windows bias. In command-line examples, both Azure CLI and Azure PowerShell are consistently provided, but there is a notable emphasis on PowerShell, a Windows-centric tool. In some sections (e.g., migration), only Windows migration is supported and documented, with Linux explicitly excluded. Throughout, Windows is often mentioned first (e.g., in region tables, OS requirements), and there is a lack of Linux-specific guidance or parity in examples. Additionally, Windows tools and patterns (like PowerShell) are given equal or greater prominence than cross-platform tools, and there are no Linux shell (bash) or scripting examples provided.
Recommendations
  • Ensure all command-line examples are clearly marked as cross-platform, and provide bash or shell script equivalents where possible, especially for Linux users.
  • When referencing PowerShell, clarify its cross-platform availability or provide alternatives (e.g., bash/Cloud Shell) for Linux users.
  • Avoid consistently listing Windows first in tables and descriptions; alternate or clarify that both OSes are equally supported where applicable.
  • For migration and other features not supported on Linux, provide clear guidance, workarounds, or timelines for Linux support.
  • Add Linux-specific notes, troubleshooting, and best practices to match the level of detail provided for Windows.
  • Review and balance the use of Windows-centric terminology and tools with Linux equivalents throughout the documentation.
GitHub Create Pull Request

Scan History

Date Scan Status Result
2026-01-13 06:17 #107 completed Biased Biased
2026-01-12 00:00 #99 completed Biased Biased
2026-01-11 06:20 #98 completed Biased Biased
2026-01-11 00:00 #95 cancelled Clean Clean
2026-01-10 00:00 #92 completed Clean Clean
2026-01-09 00:00 #87 cancelled Clean Clean
2026-01-06 22:28 #78 completed Clean Clean
2025-12-29 18:00 #48 cancelled Biased Biased
2025-12-15 00:00 #7 completed Clean Clean
2025-12-14 05:05 #6 completed Clean Clean
2025-12-14 04:32 #4 completed Clean Clean
2025-12-14 01:50 #3 completed Clean Clean

Flagged Code Snippets

#### [Azure PowerShell](#tab/azure-powershell)

You can also configure always ready instances for an app by using Azure PowerShell.


#### [Azure PowerShell](#tab/azure-powershell)

You can modify the number of prewarmed instances for an app by using the Azure PowerShell.


---

### 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:


### [Azure PowerShell](#tab/azure-powershell)

You can also increase the maximum burst limit by using Azure PowerShell:


### [Azure PowerShell](#tab/azure-powershell)

Increase the calculated minimum for a plan by using Azure PowerShell.