Azure Functions hosting options

When you create a function app in Azure, you must choose a hosting plan for your app. There are three basic hosting plans available for Azure Functions: Consumption plan, Premium plan, and Dedicated (App Service) plan. All hosting plans are generally available (GA) on both Linux and Windows virtual machines.

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 functionality, such as Azure Virtual Network connectivity.

This article provides a detailed comparison between the various hosting plans, along with Kubernetes-based hosting.

Overview of plans

The following is a summary of the benefits of the three main hosting plans for Functions:

Consumption plan Scale automatically and only pay for compute resources when your functions are running.

On the Consumption plan, instances of the Functions host are dynamically added and removed based on the number of incoming events.

✔ Default hosting plan.
✔ Pay only when your functions are running.
✔ Scales automatically, even during periods of high load.
Premium plan Automatically scales based on demand using pre-warmed 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 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 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 aren't available on the Consumption plan, such as virtual network connectivity.
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, underutilized VMs that are already running other App Service instances.
✔ You want to provide a custom image on which to run your functions.
✔ Predictive scaling and costs are required.

The comparison tables in this article also include the following hosting options, which provide the highest amount of control and isolation in which to run your function apps.

ASE App Service Environment (ASE) is an App Service feature that provides a fully isolated and dedicated environment for securely running App Service apps at high scale.

ASEs are appropriate for application workloads that require:

✔ Very high scale.
✔ Full compute isolation and secure network access.
✔ High memory usage.
Kubernetes Kubernetes provides a fully isolated and dedicated environment running on top of the Kubernetes platform.

Kubernetes is appropriate for application workloads that require:
✔ Custom hardware requirements.
✔ Isolation and secure network access.
✔ Ability to run in hybrid or multi-cloud environment.
✔ Run alongside existing Kubernetes applications and services.

The remaining tables in this article compare the plans on various features and behaviors. For a cost comparison between dynamic hosting plans (Consumption and Premium), see the Azure Functions pricing page. For pricing of the various Dedicated plan options, see the App Service pricing page.

Operating system/runtime

The following table shows supported operating system and language runtime support for the hosting plans.

Linux1
Code-only
Windows2
Code-only
Linux1,3
Docker container
Consumption plan .NET Core
Node.js
Java
Python
.NET Core
Node.js
Java
PowerShell Core
No support
Premium plan .NET Core
Node.js
Java
Python
.NET Core
Node.js
Java
PowerShell Core
.NET Core
Node.js
Java
PowerShell Core
Python
Dedicated plan .NET Core
Node.js
Java
Python
.NET Core
Node.js
Java
PowerShell Core
.NET Core
Node.js
Java
PowerShell Core
Python
ASE .NET Core
Node.js
Java
Python
.NET Core
Node.js
Java
PowerShell Core
.NET Core
Node.js
Java
PowerShell Core
Python
Kubernetes n/a n/a .NET Core
Node.js
Java
PowerShell Core
Python

1 Linux is the only supported operating system for the Python runtime stack.
2 Windows is the only supported operating system for the PowerShell runtime stack.
3 Linux is the only supported operating system for Docker containers.

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

Note

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.

Scale

The following table compares the scaling behaviors of the various hosting plans.

Scale out Max # instances
Consumption plan Event driven. Scale out automatically, even during periods of high load. Azure Functions infrastructure scales CPU and memory resources by adding additional instances of the Functions host, based on the number of incoming trigger events. 200
Premium plan Event driven. Scale out automatically, even during periods of high load. 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. 100
Dedicated plan1 Manual/autoscale 10-20
ASE1 Manual/autoscale 100
Kubernetes Event-driven autoscale for Kubernetes clusters using KEDA. Varies by cluster  

1 For specific limits for the various App Service plan options, see the App Service plan limits.

Cold start behavior

Consumption plan Apps may scale to zero when idle, meaning some requests may have additional latency at startup. The consumption plan does have some optimizations to help decrease cold start time, including pulling from pre-warmed placeholder functions that already have the function host and language processes running.
Premium plan Perpetually warm instances to avoid any cold start.
Dedicated plan When running in a Dedicated plan, the Functions host can run continuously, which means that cold start isn’t really an issue.
ASE When running in a Dedicated plan, the Functions host can run continuously, which means that cold start isn’t really an issue.
Kubernetes Depending on KEDA configuration, apps can be configured to avoid a cold start. If configured to scale to zero, then a cold start is experienced for new events.

Service limits

Resource Consumption plan Premium plan Dedicated plan ASE Kubernetes
Default timeout duration (min) 5 30 301 30 30
Max timeout duration (min) 10 unbounded7 unbounded2 unbounded unbounded
Max outbound connections (per instance) 600 active (1200 total) unbounded unbounded unbounded unbounded
Max request size (MB)3 100 100 100 100 Depends on cluster
Max query string length3 4096 4096 4096 4096 Depends on cluster
Max request URL length3 8192 8192 8192 8192 Depends on cluster
ACU per instance 100 210-840 100-840 210-2508 AKS pricing
Max memory (GB per instance) 1.5 3.5-14 1.75-14 3.5 - 14 Any node is supported
Function apps per plan 100 100 unbounded4 unbounded unbounded
App Service plans 100 per region 100 per resource group 100 per resource group - -
Storage5 5 TB 250 GB 50-1000 GB 1 TB n/a
Custom domains per app 5006 500 500 500 n/a
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 n/a

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

Networking features

Feature Consumption plan Premium plan Dedicated plan ASE Kubernetes
Inbound IP restrictions and private site access ✅Yes ✅Yes ✅Yes ✅Yes ✅Yes
Virtual network integration ❌No ✅Yes (Regional) ✅Yes (Regional and Gateway) ✅Yes ✅Yes
Virtual network triggers (non-HTTP) ❌No ✅Yes ✅Yes ✅Yes ✅Yes
Hybrid connections (Windows only) ❌No ✅Yes ✅Yes ✅Yes ✅Yes
Outbound IP restrictions ❌No ✅Yes ✅Yes ✅Yes ✅Yes

Billing

Consumption plan Pay only for the time your functions run. Billing is based on number of executions, execution time, and memory used.
Premium plan Premium plan is based on the number of core seconds and memory used across needed and pre-warmed instances. At least one instance per plan must be kept warm at all times. 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.
App Service Environment (ASE) There's a flat monthly rate for an ASE that pays for the infrastructure and doesn't change with the size of the ASE. There's also a cost per App Service plan vCPU. All apps hosted in an ASE are in the Isolated pricing SKU.
Kubernetes You pay only the costs of your Kubernetes cluster; no additional billing for Functions. Your function app runs as an application workload on top of your cluster, just like a regular app.

Next steps