Azure pricing tiers

In our previous video, we discussed Azure App Service Plan. In this video we will discuss Azure pricing tiers.

When we create App Service Plan, one of the important decisions we have to make is selecting the appropriate pricing tier, becuase it is the pricing tier that determines what features are available for the applications that we deploy in azure, the hardware that is available and the price we pay. In general, the higher the pricing tier, the more features and capabilities we get. We discussed this in detail in our previous video.

Azure Pricing Tier Categories

Azure Pricing tiers are classified into the following 3 broad categoris.

Shared compute

The free pricing tier (F1) and the shared pricing tier (D1) are in this category. With these 2 tiers, you cannot scale out resources and they use shared infrastructure. This means, all your apps run on the same Azure VM as other App Service apps, including apps of other customers.

Dedicated compute

For example, B1 and B2 pricing tiers are in this category and they run apps on dedicated Azure VMs. Only apps in the same App Service plan share the same compute resources. The higher the tier, the more VM instances are available for scale-out.

Isolated

With this tier you not only get dedicated VMs but also dedicated Virtual Networks. This means on top of compute isolation to your apps, you also get network isolation and that is made possible through virtual networks. It also provides the maximum scale-out capabilities.

Can I run more than one App in an App Service plan

Yes, you can. If multiple apps are in the same App Service plan, they all share the same VM instances. 

If you have multiple deployment slots for an app (a staging and production slot for example), all these deployment slots also run on the same VM instances. If you are new to deployment slots, we will discuss them in our upcoming videos.

Similarly, if you run WebJobs, enable diagnostic logs or perform backups, they also use CPU cycles and memory on these VM instances.

So the point is, if you have 3 VMs in your App Service Plan for example and you have deployed multiple apps, all the apps run on all the 3 VM instances. If the plan is configured to autoscale, then all apps in the plan are scaled out together based on the autoscale setting.

How many apps can I run in one App Service Plan

Well, there is no such limit. It really depends on the capabilities of your existing plan. The point is, as long as your existing plan has enough resources to handle the load, you can continue to add apps to it. However, keep in mind, deploying too many apps and overloading your plan can potentially cause downtime for both your new as well as existing apps.

How to determine if my new app needs a new plan or if I can use my already existing plan

• For example, your new app needs resources in a different geographical region than your existing apps. This may be because, your national or regional regulations require you to do so.
• May be your new app is resource inetensive and putting it in your exisitng app service plan can negatively affect already existing apps.
• May be your new app needs different set of capabilities and features altogether. For example, you want to scale this new app independently from the other apps in the existing plan.

Can I change pricing tier after the app service plan is created

Yes, you can change the pricing tier anytime you want. If you want more features or more computing power you can change to a higher pricing tier. On the other hand, if you discover you are not using all the features or computing power, you can revert to a lower pricing tier. The point is you can scale your app service plan up or down anytime simply by changing the pricing tier of the plan.

For example, if you are not sure which pricing tier is right for you, you can get started by hosting your web application in a Free App Service plan and pay nothing. If you want to add more features like a custom domain for example, you can scale up to the next higher tier that supports custom binding. If you want to add even more features or computing power, scale up to the next higher tier and so on.

You can do the opposite as well. When you no longer need the hardware or features of a higher tier, you can scale down to a lower tier, which obviously saves you money.