How to select the most suitable Hosting Plan for Azure Function App deployment?

There are six different hosting plans (AKA App service plan) available to run Azure function apps at the time of this post is being published. Which are Consumption plan, Premium Plan, Dedicated plan, ASE, Kubernetes, and Azure Arc (still in preview). I will be discussing the first three plans in this post which are know as the three main hosting plans for function apps. If you need to get an idea about these plans, or you need some key points to select a plan out of them specially with respect to the cost, this post will be helpful for you!

Let me define what is a Hosting Plan for a function app first in brief.

Even though Azure Functions is a serverless service, there is the capability to select/setup the infrastructure that we need to use Azure Function App in. Therefore, the hosting plan defines the underline infrastructure for Azure Function App. Where we can choose compute types with required CPUs, memory, and then the OS type (Linux and Windows), number of instances, and so on.

Well, that would be clear enough for now! Let’s move into the three main hosting plans.

1. Consumption Plan

• This is the lowest cost hosting plan where both Linux and Windows OS support are available. Also, this will be the default hosting plan when creating a function app.
• Supported languages for Windows hosts are C#, JavaScript, Java, PowerShell Core, and TypeScript. Linux hosts supports Python in addition to what Windows host supported.
• Event driven scale out capability is available. It adds additional instances for the host when there is an increase in the incoming events. It increases CPU and memory resources by adding new instances automatically. Maximum allowed instances for Linux is 100 and for Windows, it is 200.
• Maximum of 100 Azure Compute Units and 1.5 GB memory are allowed per instance in the host.
• 5 min default timeout and 10 min maximum timeout.
• 2 deployment slots are allowed.
• 5 TB temporary storage for the entire plan.
• Instances use cold start and drain mode is permitted up to 10 min.
• This plan only allows inbound IP restriction and there is no VNet integration support! Thus, no outbound IP restriction at all.

Break point 1:

Based on the above points, the consumption plan is more suitable for executing high frequent light weight tasks. This has the lowest power compute instances compared to other plans. Also, the maximum timeout is 10 min, that means the function should complete its job within 10 min for each and every trigger.

One of the main usages in deployment slots are to provide zero downtime updates to function apps. Since it allows 2, this is achievable.

Cold start means that there will be no dedicated up and running instances all the time for function apps. Therefore, there will be an extra latency addition for instances at their initial triggers. Drain mode defines the time permitted for instances to complete their task before calling stop.

Inbound restriction is handled with the function apps’ built-in access restriction feature. But, in order to restrict the outbound traffic, we should use virtual network integration for function app. Which is not available for this plan! That would be a major point to consider depending on the type of your app.

Following points will brief the cost considerations.

• This plan is billed per-second resource consumption and execution. Thus, we pay for the time of executions.
• It provides 400,000 GB-s execution time and 1 million total executions free of charge per month!

Break point 2:

If the dedicated workload is predictable and if it is below free allocation, this plan would be the ideal one with respective to the cost impact. However, if the downside is that the cost will be exponentially grown with this plan when free allocation is exceeded. You may use the pricing calculator to analyze the cost addition before selecting any plan (and generally for each and every cloud resource utilization).

2. Premium Plan

• Supports both Windows and Linux OS.
• Language support is as same as in consumption plan.
• Same event driven scale out is available as in the consumption plan but the max instance count is different. It is 100 for Windows and 20 for Linux. Yeah! much lower!! But you get much better compute instances from this plan!
• Maximum of 840 Azure Compute Units (ACU) and 14 GB memory is allowed per instance in the host. The exact value can be varied based on the instance type that will be selected for the plan.
• 30 min default timeout and unlimited maximum timeout is there. However, 60 min maximum timeout is guaranteed!
• 3 deployment slots are allowed. Which is 1 more than in the consumption plan.
• 250 GB temporary storage for the entire plan is available. Which is 1/4 compared to the consumption plan.
• Instances use warm start and drain mode is permitted up to 60 min.
• Virtual Network integration is supported! Thus, all inbound, outbound restrictions and private endpoints are also supported.

Break Point 3:

Based on the above points, the premium plan has much better instances than in the consumption plan. Still, it supports the scaling behavior as same as in the consumption plan. But the support of VNet integration makes it much assured with higher capabilities to handle its network routes.

Since instances have much higher timeout value, this can be used to execute long processing operations as well. High computational resources make it even easier to do the job!

Warm start behavior cut-off the extra latency that was there in the consumption plan. Because of this, the premium plan requires at least one instance allocated all the time and it impacts to the cost. Instance scheduling is much faster in the premium plan than in the consumption plan. Which reduces the possible latency further!

Thus, the premium plan might be useful for much higher time processing tasks which are not much frequent. Also, we have the controller over restricting the inbound/outbound traffic with VNet integration.

Regarding the cost considerations,

• Billing is not based on the number executions! Instead, number of core and memory allocated per second across instances will be considered.
• There is no free allocation available.
• Three costing plans are available such as pay-as-you-go, 1 year savings plan, and 3 year savings plan.

Break Point 4:

Since we should keep at lease 1 instance all time, the cost is much higher than in the consumption plan. It is expected because there are much better instances allocated in this plan too.

You may estimate the usage beforehand and how long your service is planned to be alive. When it is identified, the most suitable paying plan can be selected. Savings plans are much cheaper than the pay-as-you-go plan if the usage can be adopted with them!

3. Dedicated Plan

This a different hosting plan than above two. We need to use an Azure App Service Plan for this. Where we have 5 internal plans again within this. Which are Free, Basic, Standard, Premium, and Isolated. Don’t get confused with these plans! Just think them as sub plans inside the function app hosting plan where we have more flexibility to stick to the most suitable plan! Check out this for more details.

The dedicated plan is also called as App Service Plan in most of the places! Yeah, even in official documentations. Be mindful that these names can make some confusions. Because, I used “hosting plan” as the name to discuss these different plans. But it also called as the App Service plan for function app. Thus, hosting plan and app service plan have the same meaning when it come to the function apps’ hosting infrastructure.

However, when it comes to the dedicated plan, it uses Azure App Service plan at the bottom. Thus, get it clear that the dedicated plan is mostly named as the app service plan for function app’s hosting plan/app service plan.

If it is not clear yet, simply read below. We can use both forms.

Hosting plans for Function Apps
1. Consumption plan
2. Premium plan
3. Dedicated plan(app service plan)

App service plans for Function Apps
1. Consumption plan
2. Premium plan
3. Dedicated plan(app service plan)

Well, let’s jump back to the main topic!

In the dedicated plan,

• Both Linux and Windows are supported.
• Language support is as same as in other two plans.
• Both auto scale and manual scale are there base on the plan we choose inside the dedicated plan. The maximum CPU and Memory capacities are also varied based on the selected sub plan/instance type.
• Function timeout defaults to 30 min and has unlimited maximum value. However, the maximum value is bounded to the 120 seconds maximum value for HTTP triggers. This applied to all function app plans.
• Maximum instance count again depends on the plan/instance that we pick from available plans. e.g. no maximum count defined for Free plan. 3 for the Basic plan and 10 for the Standard plan.
• Note that High Availability with Availability Zone is only available with Premium plan under the dedicated hosting plan.
• Auto scaling is available from Standard plan to higher. Not available for Free and Basic plans.
• Virtual Network is supported for all the plans starting from Basic plan and above. Not available for the Free plan.
• Maximum Azure Compute Units and memory are as same as for the premium hosting plan.
• There will be no cold start here as we mange the hosting plan in much deeper level and allocate the worker count 1 or higher.
• Deployment slots are higher than other two plans. Which is 1–20.

Break Point 5:

According to the above points, it is clear enough that there is no much differences on computational power compared to the premium hosting plan. But it is clear that there are couple of internal service plans available in this dedicated plan. Which gives us more flexibility to select the most suitable instance type based on the use case and cost addition.

For example, if we use premium hosting plan with the lowest instance type available, the cost is much higher than the Basic service plan in the dedicated hosting plan. But still we can use Virtual network integration with the dedicated Basic plan with a lower cost which is not supported in consumption hosting plan. Likewise there are couple of points to consider which totally depend on the type of function app that we need to use.

Cost considerations,

• Free plan is there with daily CPU quota of 60 CPU mins. This is only recommended to use for development and testing purposes only.
• The billing will be calculated based on the size and the number of instances used in the plan. Thus, neither execution time nor resource utilization per second will be considered for this plan as in Consumption plan and Premium plan respectively.

Break Point 6:

You might notice another important point from the above cost consideration. Which is that if we have enough compute resources to run more function apps in the same dedicated plan, we can host them inside the same plan without an additional cost. Which is a big plus point when it come to cost saving. We can use the same Consumption or Premium plans too to host multiple function apps. But, since they consider the consumed resources over time in both those plans, there is no any cost saving with that approach.

It is always a trade off selecting one plan over other, but we should use the most suitable plan, most importantly considering the cost impact of the selection.

I recently worked on deploying Azure function app and I came up with a brief comparison with these plan in order to select the best out of them.

This post mainly consists of what I look into the most, based on the function app type that I worked with. Thus, don’t consider this as a full comparison covering each and every aspect. I just wanted to share some general knowledge on selecting a plan.

I hope this would be helpful to someone! If there is anything to discuss, let’s use the comment section below.