Events
Take the Microsoft Learn Challenge
Nov 19, 11 PM - Jan 10, 11 PM
Ignite Edition - Build skills in Microsoft Azure and earn a digital badge by January 10!
Register nowThis browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
Note
Starting June 1, 2024, all newly created App Service apps will have the option to generate a unique default hostname using the naming convention <app-name>-<random-hash>.<region>.azurewebsites.net
. Existing app names will remain unchanged.
Example: myapp-ds27dh7271aah175.westus-01.azurewebsites.net
For further details, refer to Unique Default Hostname for App Service Resource.
An app service always runs in an App Service plan. In addition, Azure Functions also has the option of running in an App Service plan. An App Service plan defines a set of compute resources for a web app to run.
When you create an App Service plan in a certain region (for example, West Europe), a set of compute resources is created for that plan in that region. Whatever apps you put into this App Service plan run on these compute resources as defined by your App Service plan. Each App Service plan defines:
The pricing tier of an App Service plan determines what App Service features you get and how much you pay for the plan. The pricing tiers available to your App Service plan depend on the operating system selected at creation time. These are the categories of pricing tiers:
Each tier also provides a specific subset of App Service features. These features include custom domains and TLS/SSL certificates, autoscaling, deployment slots, backups, Traffic Manager integration, and more. The higher the tier, the more features that are available. To find out which features are supported in each pricing tier, see App Service plan details.
You can find more comparisons between plans at App Service limits.
The PremiumV3 pricing tier guarantees machines with faster processors (minimum 195 ACU per virtual CPU), SSD storage, memory-optimized options and quadruple memory-to-core ratio compared to Standard tier. PremiumV3 also supports higher scale via increased instance count while still providing all the advanced capabilities found in Standard tier. All features available in the existing PremiumV2 tier are included in PremiumV3.
Multiple VM sizes are available for this tier, including 4-to-1 and 8-to-1 memory-to-core ratios:
For PremiumV3 pricing information, see App Service Pricing.
To get started with the new PremiumV3 pricing tier, see Configure PremiumV3 tier for App Service.
In the Free and Shared tiers, an app receives CPU minutes on a shared VM instance and cannot scale out. In other tiers, an app runs and scales as follows.
When you create an app in App Service, it's part of an App Service plan. When the app runs, it runs on all the VM instances configured in the App Service plan. 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, all deployment slots also run on the same VM instances. If you enable diagnostic logs, perform backups, or run WebJobs, they also use CPU cycles and memory on these VM instances.
In this way, the App Service plan is the scale unit of the App Service apps. If the plan is configured to run five VM instances, then all apps in the plan run on all five instances. If the plan is configured for autoscaling, then all apps in the plan are scaled out together based on the autoscale settings.
For information on scaling out an app, see Scale instance count manually or automatically.
This section describes how App Service apps are billed. For detailed, region-specific pricing information, see App Service Pricing.
Except for the Free tier, an App Service plan carries a charge on the compute resources it uses.
You don't get charged for using the App Service features that are available to you (configuring custom domains, TLS/SSL certificates, deployment slots, backups, etc.). The exceptions are:
Note
If you integrate App Service with another Azure service, you may need to consider charges from these other services. For example, if you use Azure Traffic Manager to scale your app geographically, Azure Traffic Manager also charges you based on your usage. To estimate your cross-services cost in Azure, see Pricing calculator.
Want to optimize and save on your cloud spending?
Azure services cost money. Azure Cost Management helps you set budgets and configure alerts to keep spending under control. Analyze, manage, and optimize your Azure costs with Cost Management. To learn more, see the quickstart on analyzing your costs.
Your App Service plan can be scaled up and down at any time. It's as simple as changing the pricing tier of the plan. You can choose a lower pricing tier at first and scale up later when you need more App Service features.
For example, you can start testing your web app in a Free App Service plan and pay nothing. When you add your custom DNS name to the web app, just scale your plan up to Shared tier. Later, when you want to create a TLS binding, scale your plan up to Basic tier. When you want to have staging environments, scale up to Standard tier. When you need more cores, memory, or storage, scale up to a bigger VM size in the same tier.
The same works in reverse. When you feel you no longer need the capabilities or features of a higher tier, you can scale down to a lower tier, which saves you money.
For information on scaling up the App Service plan, see Scale up an app in Azure.
If your app is in the same App Service plan with other apps, you may want to improve the app's performance by isolating the compute resources. You can do this by moving the app into a separate App Service plan. For more information, see Move an app to another App Service plan.
Since you pay for the computing resources your App Service plan allocates (see How much does my App Service plan cost?), you can potentially save money by putting multiple apps into one App Service plan. You can continue to add apps to an existing plan as long as the plan has enough resources to handle the load. However, keep in mind that apps in the same App Service plan all share the same compute resources. To determine whether the new app has the necessary resources, you need to understand the capacity of the existing App Service plan, and the expected load for the new app. Overloading an App Service plan can potentially cause downtime for your new and existing apps.
Isolate your app into a new App Service plan when:
The app is resource-intensive. The number may actually be lower depending on how resource intensive the hosted applications are. However, for general guidance, refer to the table below:
App Service Plan SKU | Maximum Apps |
---|---|
B1, S1, P1v2, I1v1 | 8 |
B2, S2, P2v2, I2v1 | 16 |
B3, S3, P3v2, I3v1 | 32 |
P0v3 | 8 |
P1v3, I1v2 | 16 |
P2v3, I2v2, P1mv3 | 32 |
P3v3, I3v2, P2mv3 | 64 |
I4v2, I5v2, I6v2 | Maximum density bound by vCPU usage |
P3mv3, P4mv3, P5mv3 | Maximum density bound by vCPU usage |
You want to scale the app independently from the other apps in the existing plan.
The app needs resources in a different geographical region.
This way you can allocate a new set of resources for your app and gain greater control of your apps.
Note
An active slot is also classified as an active app because it too is competing for resources on the same App Service Plan.
Events
Take the Microsoft Learn Challenge
Nov 19, 11 PM - Jan 10, 11 PM
Ignite Edition - Build skills in Microsoft Azure and earn a digital badge by January 10!
Register now