Events
Mar 17, 11 PM - Mar 21, 11 PM
Join the meetup series to build scalable AI solutions based on real-world use cases with fellow developers and experts.
Register nowThis browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
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 | GA | None |
Azure Functions hosting options are facilitated by Azure App Service infrastructure on both Linux and Windows virtual machines. The hosting option you choose dictates the following behaviors:
The plan you choose also impacts the costs for running your function code. For more information, see 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.
The following is a summary of the benefits of the various options for Azure Functions hosting:
Option | Benefits |
---|---|
Flex Consumption plan | Get rapid horizontal scaling with compute choices, virtual networking, and pay-as-you-go billing. On the Flex Consumption plan, instances of the Functions host are dynamically added and removed based on the configured per instance concurrency and the number of incoming events. ✔ Reduce cold starts by specifying one or more pre-provisioned (always ready) instances. ✔ Supports virtual networking for added security. ✔ Pay when your functions are running. ✔ Scales automatically, even during periods of high load. |
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. Consider the Azure Functions Premium plan in the following situations: ✔ Your function apps run continuously, or nearly continuously. ✔ You want more control of your instances and want to deploy multiple function apps on the same plan with event-driven scaling. ✔ 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 are provided by consumption plans. ✔ Your code needs to run longer than the maximum execution time allowed on the Consumption plan. ✔ You require virtual network connectivity. ✔ 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. Best for long-running scenarios where Durable Functions can't be used. Consider an App Service plan in the following situations: ✔ You have existing and underutilized virtual machines that are already running other App Service instances. ✔ You must have fully predictable billing, or you need to manually scale instances. ✔ You want to run multiple web apps and function apps on the same plan ✔ You need access to larger compute size choices. ✔ Full compute isolation and secure network access provided by an App Service Environment (ASE). ✔ 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. 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: ✔ You want to package custom libraries with your function code to support line-of-business apps. ✔ You need to migrate code execution from on-premises or legacy apps to cloud native microservices running in containers. ✔ When you want to avoid the overhead and complexity of managing Kubernetes clusters and dedicated compute. ✔ 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 the Consumption plan, instances of the Functions host are dynamically added and removed based on the number of incoming events. ✔ Default hosting plan that provides true serverless hosting. ✔ Pay only when your functions are running. ✔ Scales automatically, even during periods of high load. |
The remaining tables in this article compare hosting options based on various features and behaviors.
This table shows operating system support for the hosting options.
Hosting | Linux1 deployment | Windows2 deployment |
---|---|---|
Flex Consumption plan | ✅ Code-only ❌ Container (not supported) |
❌ Not supported |
Premium plan | ✅ Code-only ✅ Container |
✅ Code-only |
Dedicated plan | ✅ Code-only ✅ Container |
✅ Code-only |
Container Apps | ✅ Container-only | ❌ Not supported |
Consumption plan | ✅ Code-only ❌ Container (not supported) |
✅ Code-only |
The time-out duration for functions in a function app is defined by the functionTimeout
property in the host.json project file. This property applies specifically to function executions. After the trigger starts function execution, the function needs to return/respond within the time-out duration. To avoid time-outs, it's important to write robust functions. For more information, see Improve Azure Functions performance and reliability.
The following table shows the default and maximum values (in minutes) for specific plans:
Plan | Default | Maximum1 |
---|---|---|
Flex Consumption plan | 30 | Unbounded2 |
Premium plan | 304 | Unbounded2 |
Dedicated plan | 304 | Unbounded3 |
Container Apps | 30 | Unbounded5 |
Consumption plan | 5 | 10 |
For details on current native language stack support in Functions, see Supported languages in Azure Functions.
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 | Per-function scaling. Event-driven scaling decisions are calculated on a per-function basis, which provides a more deterministic way of scaling the functions in your app. With the exception of 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. | 10005 |
Premium plan | Event driven. 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 Linux: 20-1002 |
Dedicated plan3 | Manual/autoscale | 10-30 100 (ASE) |
Container Apps | Event driven. 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-10004 |
Consumption plan | Event driven. Scales out automatically, even during periods of high load. Functions infrastructure scales CPU and memory resources by adding more instances of the Functions host, based on the number of incoming trigger events. | Windows: 200 Linux: 1001 |
Plan | Details |
---|---|
Flex Consumption plan | Supports always ready instances to reduce the delay when provisioning new instances. |
Premium plan | Supports always ready instances to avoid cold starts by letting you maintain one or more perpetually warm instances. |
Dedicated plan | When running 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: • When set to zero: apps can scale to zero when idle and some requests might have more latencies at startup. • 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. |
Resource | Flex Consumption plan | Premium plan | Dedicated plan/ASE | Container Apps | Consumption plan |
---|---|---|---|---|---|
Default time-out duration (min) | 30 | 30 | 301 | 3016 | 5 |
Max time-out duration (min) | unbounded9 | unbounded9 | unbounded2 | unbounded17 | 10 |
Max outbound connections (per instance) | unbounded | unbounded | unbounded | unbounded | 600 active (1200 total) |
Max request size (MB)3 | 210 | 210 | 210 | 210 | 210 |
Max query string length3 | 4096 | 4096 | 4096 | 4096 | 4096 |
Max request URL length3 | 8192 | 8192 | 8192 | 8192 | 8192 |
ACU per instance | 210-840 | 100-840/210-25010 | varies | 100 | varies |
Max memory (GB per instance) | 414 | 3.5-14 | 1.75-256/8-256 | varies | 1.5 |
Max instance count (Windows | Linux) | n/a | 100015 | varies by S KU | 10011 | 10-30018 | 200 | 100 | 1000 |
Function apps per plan13 | 1 | 100 | unbounded4 | unbounded4 | 100 |
App Service plans | n/a | 100 per resource group | 100 per resource group | n/a | 100 per region |
Deployment slots per app12 | n/a | 3 | 1-2011 | not supported | 2 |
Storage (temporary)5 | 0.8 GB | 21-140 GB | 11-140 GB | n/a | 0.5 GB |
Storage (persisted) | 0 GB7 | 250 GB | 10-1000 GB11 | n/a | 1 GB6,7 |
Custom domains per app | 500 | 500 | 500 | not supported | 5007 |
Custom domain TSL/SSL support | unbounded SNI SSL and one IP SSL connection included | unbounded SNI SSL and one IP SSL connection included | unbounded SNI SSL and one IP SSL connection included | not supported | unbounded SNI SSL connection included |
Notes on service limits:
Feature | Flex Consumption plan | Consumption plan | Premium plan | Dedicated plan/ASE | Container Apps1 |
---|---|---|---|---|---|
Inbound IP restrictions | ✔ | ✔ | ✔ | ✔ | ✔ |
Inbound Private Endpoints | ✔ | ✔ | ✔ | ||
Virtual network integration | ✔ | ✔2 | ✔3 | ✔ | |
Outbound IP restrictions | ✔ | ✔ | ✔ | ✔ |
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. For more information, see Flex Consumption plan 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. 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 SKU. For more information, see the ASE overview article. |
Container Apps | Billing in Azure Container Apps is based on your plan type. For more information, see Billing in Azure Container Apps. |
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. For pricing of the various Dedicated plan options, see the App Service pricing page. For pricing Container Apps hosting, see Azure Container Apps pricing.
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:
This can happen when the following conditions are met:
The reason this happens is due to how function app and web app plans are mapped to different pools of resources when being created. Different SKUs 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, this error occurs.
When this error occurs, instead create your function app and hosting plan in a new resource group.
Events
Mar 17, 11 PM - Mar 21, 11 PM
Join the meetup series to build scalable AI solutions based on real-world use cases with fellow developers and experts.
Register nowTraining
Learning path
Run high-performance computing (HPC) applications on Azure - Training
Azure HPC is a purpose-built cloud capability for HPC & AI workload, using leading-edge processors and HPC-class InfiniBand interconnect, to deliver the best application performance, scalability, and value. Azure HPC enables users to unlock innovation, productivity, and business agility, through a highly available range of HPC & AI technologies that can be dynamically allocated as your business and technical needs change. This learning path is a series of modules that help you get started on Azure HPC - you