Azure Functions scale and hosting

When you create a function app in Azure, you must choose a hosting plan for your app. There are three hosting plans available for Azure Functions: Consumption plan, Premium plan, and Dedicated (App Service) plan.

The hosting plan you choose dictates the following behaviors:

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

Both Consumption and Premium plans automatically add compute power when your code is running. Your app is scaled out when needed to handle load, and scaled in when code stops running. For the Consumption plan, you also don't have to pay for idle VMs or reserve capacity in advance.

Premium plan provides additional features, such as premium compute instances, the ability to keep instances warm indefinitely, and VNet connectivity.

App Service plan allows you to take advantage of dedicated infrastructure, which you manage. Your function app doesn't scale based on events, which means is never scales in to zero. (Requires that Always on is enabled.)

Hosting plan support

Feature support falls into the following two categories:

  • Generally available (GA): fully supported and approved for production use.
  • Preview: not yet fully supported nor approved for production use.

The following table indicates the current level of support for the three hosting plans, when running on either Windows or Linux:

Consumption plan Premium plan Dedicated plan
Windows GA GA GA
Linux GA GA GA

Consumption plan

When you're using the Consumption plan, instances of the Azure Functions host are dynamically added and removed based on the number of incoming events. This serverless plan scales automatically, and you're charged for compute resources only when your functions are running. On a Consumption plan, a function execution times out after a configurable period of time.

Billing is based on number of executions, execution time, and memory used. Billing is aggregated across all functions within a function app. For more information, see the Azure Functions pricing page.

The Consumption plan is the default hosting plan and offers the following benefits:

  • Pay only when your functions are running
  • Scale out automatically, even during periods of high load

Function apps in the same region can be assigned to the same Consumption plan. There's no downside or impact to having multiple apps running in the same Consumption plan. Assigning multiple apps to the same Consumption plan has no impact on resilience, scalability, or reliability of each app.

To learn more about how to estimate costs when running in a Consumption plan, see Understanding Consumption plan costs.

Premium plan

When you're using the Premium plan, instances of the Azure Functions host are added and removed based on the number of incoming events just like the Consumption plan. Premium plan supports the following features:

  • Perpetually warm instances to avoid any cold start
  • VNet connectivity
  • Unlimited execution duration (60 minutes guaranteed)
  • Premium instance sizes (one core, two core, and four core instances)
  • More predictable pricing
  • High-density app allocation for plans with multiple function apps

Information on how you can configure these options can be found in the Azure Functions Premium plan document.

Instead of billing per execution and memory consumed, billing for the Premium plan is based on the number of core seconds and memory used across needed and pre-warmed instances. At least one instance must be warm at all times per plan. This means that there is a minimum monthly cost per active plan, regardless of the number of executions. Keep in mind that all function apps in a Premium plan share pre-warmed and active instances.

Consider the Azure Functions Premium plan in the following situations:

  • Your function apps run continuously, or nearly continuously.
  • You have a high number of small executions and have a high execution bill but low GB second bill in the Consumption plan.
  • You need more CPU or memory options than what is provided by the Consumption plan.
  • Your code needs to run longer than the maximum execution time allowed on the Consumption plan.
  • You require features that are only available on a Premium plan, such as virtual network connectivity.

When running JavaScript functions on a Premium plan, you should choose an instance that has fewer vCPUs. For more information, see the Choose single-core Premium plans.

Dedicated (App Service) plan

Your function apps can also run on the same dedicated VMs as other App Service apps (Basic, Standard, Premium, and Isolated SKUs).

Consider an App Service plan in the following situations:

  • You have existing, underutilized VMs that are already running other App Service instances.
  • You want to provide a custom image on which to run your functions.

You pay the same for function apps in an App Service Plan as you would for other App Service resources, like web apps. For details about how the App Service plan works, see the Azure App Service plans in-depth overview.

With an App Service plan, you can manually scale out by adding more VM instances. You can also enable autoscale. For more information, see Scale instance count manually or automatically. You can also scale up by choosing a different App Service plan. For more information, see Scale up an app in Azure.

When running JavaScript functions on an App Service plan, you should choose a plan that has fewer vCPUs. For more information, see Choose single-core App Service plans.

Always On

If you run on an App Service plan, you should enable the Always on setting so that your function app runs correctly. On an App Service plan, the functions runtime goes idle after a few minutes of inactivity, so only HTTP triggers will "wake up" your functions. Always on is available only on an App Service plan. On a Consumption plan, the platform activates function apps automatically.

Function app timeout duration

The timeout duration of a function app is defined by the functionTimeout property in the host.json project file. The following table shows the default and maximum values in minutes for both plans and the different runtime versions:

Plan Runtime Version Default Maximum
Consumption 1.x 5 10
Consumption 2.x 5 10
Consumption 3.x 5 10
Premium 1.x 30 Unlimited
Premium 2.x 30 Unlimited
Premium 3.x 30 Unlimited
App Service 1.x Unlimited Unlimited
App Service 2.x 30 Unlimited
App Service 3.x 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.

Even with Always On enabled, the execution timeout for individual functions is controlled by the functionTimeout setting in the host.json project file.

Determine the hosting plan of an existing application

To determine the hosting plan used by your function app, see App Service plan in the Overview tab for the function app in the Azure portal. To see the pricing tier, select the name of the App Service Plan, and then select Properties from the left pane.

View scaling plan in the portal

You can also use the Azure CLI to determine the plan, as follows:

appServicePlanId=$(az functionapp show --name <my_function_app_name> --resource-group <my_resource_group> --query appServicePlanId --output tsv)
az appservice plan list --query "[?id=='$appServicePlanId'].sku.tier" --output tsv

When the output from this command is dynamic, your function app is in the Consumption plan. When the output from this command is ElasticPremium, your function app is in the Premium plan. All other values indicate different tiers of an App Service plan.

Storage account requirements

On any plan, a function app requires a general Azure Storage account, which supports Azure Blob, Queue, Files, and Table storage. This is because Azure Functions relies on Azure Storage for operations such as managing triggers and logging function executions, but some storage accounts do not support queues and tables. These accounts, which include blob-only storage accounts (including premium storage) and general-purpose storage accounts with zone-redundant storage replication, are filtered-out from your existing Storage Account selections when you create a function app.

The same storage account used by your function app can also be used by your triggers and bindings to store your application data. However, for storage-intensive operations, you should use a separate storage account.

It's certainly possible for multiple function apps to share the same storage account without any issues. (A good example of this is when you develop multiple apps in your local environment using the Azure Storage Emulator, which acts like one storage account.)

To learn more about storage account types, see Introducing the Azure Storage services.

How the Consumption and Premium plans work

In the Consumption and Premium plans, the Azure Functions infrastructure scales CPU and memory resources by adding additional instances of the Functions host, based on the number of events that its functions are triggered on. Each instance of the Functions host in the Consumption plan is limited to 1.5 GB of memory and one CPU. An instance of the host is the entire function app, meaning all functions within a function app share resource within an instance and scale at the same time. Function apps that share the same Consumption plan are scaled independently. In the Premium plan, your plan size will determine the available memory and CPU for all apps in that plan on that instance.

Function code files are stored on Azure Files shares on the function's main storage account. When you delete the main storage account of the function app, the function code files are deleted and cannot be recovered.

Runtime scaling

Azure Functions uses a component called the scale controller to monitor the rate of events and determine whether to scale out or scale in. The scale controller uses heuristics for each trigger type. For example, when you're using an Azure Queue storage trigger, it scales based on the queue length and the age of the oldest queue message.

The unit of scale for Azure Functions is the function app. When the function app is scaled out, additional resources are allocated to run multiple instances of the Azure Functions host. Conversely, as compute demand is reduced, the scale controller removes function host instances. The number of instances is eventually scaled in to zero when no functions are running within a function app.

Scale controller monitoring events and creating instances

Understanding scaling behaviors

Scaling can vary on a number of factors, and scale differently based on the trigger and language selected. There are a few intricacies of scaling behaviors to be aware of:

  • A single function app only scales out to a maximum of 200 instances. A single instance may process more than one message or request at a time though, so there isn't a set limit on number of concurrent executions.
  • For HTTP triggers, new instances are allocated, at most, once per second.
  • For non-HTTP triggers, new instances are allocated, at most, once every 30 seconds. Scaling is faster when running in a Premium plan.
  • For Service Bus triggers, use Manage rights on resources for the most efficient scaling. With Listen rights, scaling isn't as accurate because the queue length can't be used to inform scaling decisions. To learn more about setting rights in Service Bus access policies, see Shared Access Authorization Policy.
  • For Event Hub triggers, see the scaling guidance in the reference article.

Best practices and patterns for scalable apps

There are many aspects of a function app that will impact how well it will scale, including host configuration, runtime footprint, and resource efficiency. For more information, see the scalability section of the performance considerations article. You should also be aware of how connections behave as your function app scales. For more information, see How to manage connections in Azure Functions.

For more information on scaling in Python and Node.js, see Azure Functions Python developer guide - Scaling and concurrency and Azure Functions Node.js developer guide - Scaling and concurrency.

Billing model

Billing for the different plans is described in detail on the Azure Functions pricing page. Usage is aggregated at the function app level and counts only the time that function code is executed. The following are units for billing:

  • Resource consumption in gigabyte-seconds (GB-s). Computed as a combination of memory size and execution time for all functions within a function app.
  • Executions. Counted each time a function is executed in response to an event trigger.

Useful queries and information on how to understand your consumption bill can be found on the billing FAQ.

Service limits

The following table indicates the limits that apply to function apps when running in the various hosting plans:

Resource Consumption plan Premium plan App Service plan1
Scale out Event driven Event driven Manual/autoscale
Max instances 200 100 10-20
Default timeout duration (min) 5 30 302
Max timeout duration (min) 10 unbounded8 unbounded3
Max outbound connections (per instance) 600 active (1200 total) unbounded unbounded
Max request size (MB)4 100 100 100
Max query string length4 4096 4096 4096
Max request URL length4 8192 8192 8192
ACU per instance 100 210-840 100-840
Max memory (GB per instance) 1.5 3.5-14 1.75-14
Function apps per plan 100 100 unbounded5
App Service plans 100 per region 100 per resource group 100 per resource group
Storage6 1 GB 250 GB 50-1000 GB
Custom domains per app 5007 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

1 For specific limits for the various App Service plan options, see the App Service plan limits.
2 By default, the timeout for the Functions 1.x runtime in an App Service plan is unbounded.
3 Requires the App Service plan be set to Always On. Pay at standard rates.
4 These limits are set in the host.
5 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.
6 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.
7 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.
8 Guaranteed for up to 60 minutes.