What Are Azure Web App Service Plans?

What Are the Azure App Service Plans? In this post, I will explain how elements of the Azure App Service (except Functions) are executed in instances of an Azure App Service plan and what those plans are.
 

 

Under the Covers

The Azure App Service offers several services for running your line-of-business (LOB) application code:

• Web Apps
• Web Jobs
• Mobile Jobs
• API Apps
• Logic Apps
• Functions

All but Functions from the above list are executed inside of virtual machines that are abstracted and managed by the Azure Service Fabric.

 
Those virtual machines:

• Must be sized to determine RAM and processor capacities
• Tiered by Microsoft so that you get more functionality for higher spec machines
• Must be paid for based on the tier that is chosen, the size used within that tier, and the consumption of that tier
• Execute in a specific Azure region

The role of the App Service Plan is to specify a series of virtual machines with a set of capabilities and to size the virtual machine’s RAM and processor capacities.
When you deploy a new Web App, API App, mobile app, or Web Job it will be assigned to an App Service Plan in a specific Azure region. Think of this as deploying an app into a virtual machine. You will choose a tier (a set of capabilities) and the size (processor and RAM) of the plan, so ensure that the plan will have sufficient resources and functions for your app. Once deployed, you choose the scale-out of the plan or how many virtual machines (or instances) will host and load balance the app at once.
There is some elasticity after you have deployed an app. You might find that you need to increase or decrease the set of available features that an app is using. For example, you can develop and test a web app in a plan that was deployed in the free tier, which offers very few features. You can later move the app to a paid-for-plan that offers more functionality, so you can conduct UAT and switch to production. It is possible to move an app back to a lower plan but you must first disable any features that are not available in that lower plan. Think of these upgrades and downgrades as moving an app (with a few clicks) between virtual machines of different capabilities.

You also can control the number of instances within a plan, which impacts performance, fault tolerance, and cost. Under the covers, additional virtual machines are used to host the app when you scale out, or some machines are decommissioned when you scale in, and load balancing and content availability are managed automatically for you.

Comparing the Plan Tiers

Microsoft has shared a very detailed breakdown of the tiers of App Service Plans but I will describe them quickly here. There are 7 tiers/versions of plan tiers for hosting elements of the Azure Service Fabric (excluding Functions which are server-less). Each tier offers different features and scalability.

 
The entry level tier is the Free tier, which is free to use; it is intended for test/dev scenarios but I also like this tier for temporary websites where the domain name is not that important.
The Shared tier, which has been in preview for as long as I can remember, is a low-cost plan. Here, you host websites with custom domain names (not possible in the free tier) but on shared resources. Once again, this is a good plan for test/dev and for low requirements web apps.
The Basic tier is what Microsoft would consider as the entry level for production apps and services. This allows for unlimited web services to be hosted on up to 3 load balanced instances. A 99.95 percent SLA is available and you can use SSL certificates.
The Standard tier offers instance scale-out for up to 10 virtual machines. Scale-out/in can be automated using a performance monitoring feature called auto-scale. Importantly, support for backing up your website/database is included in this tier. Other interesting features that you get with the Standard plan are hybrid connectivity (connect your app to an Azure virtual network via VPN) and staging environments (create test/dev/production deployment slots or clones of an app).
Recently Microsoft added a Premium v2 tier to the already present Premium Tier. The Premium v2 tier is based on D_v2 virtual machines and substantially boosts the performance of each instance over what was included in the older Premium tier. A single plan can scale out up to 50 instances and have greater capacities of each resource/function.

The virtual machines of the above plans are not connected to a virtual network in Azure. They are effectively presented “naked” to the Internet. That is not quite true but there’s no old-fashioned firewall appliance in front of the Free-Premium instances. This is a deal breaker for some organizations because they are stuck on security models from the 1990s. For those organizations, Microsoft has launched a new Isolated tier where the instances are on a virtual network and isolated from the Internet. This is known as App Service Environment (ASE). Note that the machines used in this tier appear to be those from the Premium V2 tier. A deployment is quite expensive because you must pay for each instance and a substantial flat fee for each ASE.