App Service plans represent the collection of physical resources used to host your apps.1
App Service plans define:
- Region (West US, East US, etc.)
- Scale count (one, two, three instances, etc.)
- Instance size (Small, Medium, Large)
- SKU (Free, Shared, Basic, Standard, Premium)
Web Apps, Mobile Apps, API Apps, Function Apps (or Functions), in Azure App Service all run in an App Service plan. Apps in the same subscription, region, and resource group can share an App Service plan.
All applications assigned to an App Service plan share the resources defined by it. This sharing saves money when hosting multiple apps in a single App Service plan.
Your App Service plan can scale from Free and Shared SKUs to Basic, Standard, and Premium giving you access to more resources and features along the way.
If your App Service plan is set to Basic SKU or higher, then you can control the size and scale count of the VMs.
For example, if your plan is configured to use two “small” instances in the standard service tier, all apps that are associated with that plan run on both instances. Apps also have access to the standard service tier features. Plan instances on which apps are running are fully managed and highly available.
This article explores the key characteristics, such as tier and scale, of an App Service plan and how they come into play while managing your apps.
Apps and App Service plans
An app in App Service can be associated with only one App Service plan at any given time.
Both apps and plans are contained in a resource group. A resource group serves as the lifecycle boundary for every resource that’s within it. You can use resource groups to manage all the pieces of an application together.
Because a single resource group can have multiple App Service plans, you can allocate different apps to different physical resources.
For example, you can separate resources among dev, test, and production environments. Having separate environments for production and dev/test lets you isolate resources. In this way, load testing against a new version of your apps does not compete for the same resources as your production apps, which are serving real customers.
When you have multiple plans in a single resource group, you can also define an application that spans geographical regions.
For example, a highly available app running in two regions includes at least two plans, one for each region, and one app associated with each plan. In such a situation, all the copies of the app are then contained in a single resource group. Having a resource group with multiple plans and multiple apps makes it easy to manage, control, and view the health of the application.