What is an Azure App Service Plan and what does it do?

App Service, Azure, App Service Plan, Web App

A web app in Azure actually consists of two things, an App Service Plan and an App Service, what is not always clear is why they are two things and what the purpose of the plan part is. The App Service is fairly easy to understand, it’s the actual instance of your web application, it’s where you deploy your code, set up SSL certificates, connection strings etc. The App Service Plan is a little less clear, when you create your app you select a plan and this determines what you pay, but it’s not entirely obvious what it is for, why it’s a separate things, or what you can do with it. What’s even more confusing is that the answer to this can vary depending on the tier of web app chosen. Hopefully in this article we can clear a bit of that up.

An App Service Plan, at a very high level is the container in which your web applications run, it is used to determine the resources available to your application (or applications) and their boundary. Comparing this to an on premises environment, the app service environment is the server, or servers on which your application is deployed. The app service plan defines what specification of hardware your app runs on, and how many servers you have. The Free and Shared plans differ slightly here in that you are sharing a VM with other users, so the delineation is on resources rather than machines.

The app service plan being separate from the web app its self may be confusing until you understand something that many of those starting their journey with web apps do not, you can deploy multiple web apps in the same app service plan, you do not need a separate web app plan for each web app. Generally the price you pay is for the web app plan and not the web app (the shared plan is an exception to this, see later) so your costs do not increase as you add more applications to the same plan.

One thing to be aware of when putting applications in the same plan however. As you know, the web app plan controls the specification of your “web servers” and how many of them there are. Because of this all of the apps in the same app service plan will share the same resources, so if you have one demanding application it can starve others of resources. Similarly if you have a need to scale up to multiple instances to support one app, all of your apps in the same app service plan will be deployed to all instances and if you use auto scale then any one of them can trigger the auto scale. Finally, all web apps in an app service plan will be in the same region.

Web App Plan Tiers

As I mentioned, the benefit and costs of the app service plan varies between different tiers of web apps, which makes this even more confusing. So before you start loading up your app service plans with multiple apps, make sure you are aware of how your chosen plan implements this. At the present time there are 4 tiers in Azure Web Apps:

  • Free
  • Shared
  • Dedicated – These are the plans labeled Basic, Standard, Premium and PremiumV2)
  • Isolated – This is the App Service Environment (a dedicated deployment in your vNet)

Let’s take a look at these and determine how their App Service Plan works for each of them.

Free

The  free plan is,  as you would expect, free so the web app plan has no impact on the pricing. The free tier is limited to 60 CPU minutes per day, and this limit is per app, so in reality it doesn’t really matter if you put each app in it’s own plan or share one (there is a limit of 10 apps per free plan).

Shared

The shared plan is where things get a bit confusing. Like the free plan you are sharing hardware and you are allocated a CPU limit, this time of 240 CPU minutes per day. You can host up to 100 apps in a single app service plan, but the key thing to know here is that as with the free plan you are charged per app, not per app service plan. Each instance of a web app you deploy in the shared plan get’s it’s own 240 CPU minutes limit and is charged per app. So in this scenario having multiple app plans or one app plan doesn’t really make much difference (and usually a single app plan is better for management overhead).

This is one of the key things that people often don’t notice when comparing the price between shared and the higher tiers. It looks like there is a pretty large price jump, and there is if you are only hosting 1 application, but if you are hosting multiple apps then the difference can be significantly less if they are OK sharing the resources.

Dedicated

The dedicated instance tier contains most of the general workload sizes – Basic, Standard and Premium. They are called dedicated because in each of these options you are running on dedicated VM’s just for you. As these VM’s are dedicated to you, you get full use of all of the resources in the VM’s and can run as many apps as you want on them. There are two directions you can go to change the pricing with these plans:

  1. Change plan – as you scale up the plans Basic -> Standard 1 -> Standard 2 etc. you increase the size of the VM you are running on and so get access to more resource
  2. Change the number of instances – you can stay on the same plan and scale out so you have more instances with the same resources, you will be charged per instance and all of your apps in the same plan will run on all instances

Isolated

Isolated means you are running an App Service Environment, this is a private instance of all of the web app infrastructure deployed into your own virtual network. In an ASE you are charged a fixed fee for running the environment plus a variable price based on the number of instances (worker virtual machines) you require. As with the dedicated app plans, each web app plan is running on it’s own hardware. To give an example, the following would all require 10 ASE worker instances (and so have the same cost):

  • 1 app service plan with 10 instances
  • 10 app service plans with 1 instance each
  • 1 app service plan with 4 instances and another app service plan with 6 instances

As with the dedicated tier, you can also scale up your worker nodes to get more resources per machine (and instance pricing goes up accordingly).

 

Summary

The fact that it has taken a page to explain the differences between each plan type and how they are charged highlights how confusing this all can be. Because of this I suspect there are people out there wasting a fairly large amount of money running each of their dedicated instances in it’s own play where they really didn’t need to. If we summarise the above I would generally follow the following decision tree:

  • If it’s a demanding application that needs lot’s of resources or could impact other apps, I’ll put it in it’s own plan
  • If I am going to need to scale the number of instances differently for one app compared to another, they will get their own plan, especially if I am going to use auto scale
  • If apps need to be in different regions they need to be in different plans (but apps in the same region can all share)
  • If I am using the free or shared tier I’ll generally put things in the same plan just for organisation and not to clutter up the portal

Hopefully this has cleared up what the point in the app service plan is, and what use they could be for you.