Working with Apps, Slots and Plans in Azure WebApps

After Azure Portal officially introduced slots, I got many questions related to deployment of an application. I hope this short article can clarify how azure App Services are deployed under the hub.

When installing multiple applications under one App Service Plan, then all apps by default physically run in context of that Service Plan. Once you define an App Service Plan for the app, the app will be physically deployed in the container, which runs in process w3wp.exe. This is well known process behind Internet Information Server (IIS).
For every application, a single plan must be chosen, which defines the power of machine, which host app container and many other behaviors, like number of supported slots, backups, etc. Following picture shows some of plans.

If you chose for example S1, you can horizontally scale your application up to 10 instances. Additionally, you can use up to 5 slots. If you chose premium P3, you can scale horizontally up to 20 instances etc.  In general, at moment of writing of this article, App Service Plans in the Standard tier (S plans) can have up to 10 compute resources, while App Service Plans in the Premium tier (P plans) can have up to 20 compute resources.
In any case, your application will be deployed in w3wp.exe, which will run on machine which you have selected. If you run application on 2 instances, application will be deployed on two different (virtual) machines in w3wp.exe running on each machine.

Every App Service Plans always contain a minimum of one compute resource, which is by default your application. However, slots are also defined as apps, which require compute resources. Because of that slots as such also run in App Service Plans.

All apps and slots associated with a given App Service Plan will run a w3wp.exe process on each and every compute resource contained in the App Service Plan. So if you have (4) different apps allocated to an App Service Plan with (8) S2 compute resources, you have will have (4) w3wp.exe processes running on each of the (8) S2 resources.

By default, if you don't change default slot settings all apps (both the production slot, and all of an app's other slots) will be running in the same App Service Plan. If that service plan defines a single compute resource (single machine), your app and apps in slots will run in the same w3wp.exe. Some people think they could purchase a single machine and deploy few different applications in slots of the same plan and save money. This does not make really sense. You will truly pay less for this configuration, but you will also truly get less resources. Remember, all apps will be deployed in a single process.

However you can change the App Service Plan that a slot runs on, including creating a brand new App Service Plan and placing a slot (or multiple slots if you want) into the new App Service Plan.
For example, let’s assume we have two slots as shown at the picture below.

By default every slot shares the plan of the application, where slots have been created.

If you want to change the plan of the slot, you can do it as shown at the next picture:

This will physically deploy slots to different physical (virtualized) resources.
One thing to keep in mind is that if you flip-flop live production traffic between one (or more) slots, and each of your slot(s) is in a different App Service Plan, make sure to choose the same quantity and type of compute resources for each of your App Service Plans. You don't want to accidentally have Production running on a few S3s, and then swap over to a slot running on a single S1 (as an example.

Be careful when creating slots. If they are created in the same app plans (which is by default), slots will share same physical resources with the application in production.  If you chose different plan for slots, you will get more physical resources, but you will have to pay more money.

As you see, slots provide us very high flexibility when testing and deploying applications.