Demystifying Azure App Services Plan

Microsoft Azure cloud hero

In my last article we looked at some of the physical characteristics of an Azure App Service and saw how every app deploys into a scale unit. In this post, we’ll continue looking behind the scenes of how an App Service works and focus on some of the aspects of an App Service plan.

Make a Plan

When you create an App Service, you need to place the App Service into an App Service plan. The plan describes the virtual machine that will host your app service. Every plan tells you how much memory the machine will have, as well as the number of ACUs (Azure Compute Units) available. In the past, we would see the number of CPUs in each plan, but not every CPU is equal. Azure now uses ACUs to provide a better relative measurement of the processing power for a plan.

It is important to understand that every App Service requires a plan. But, it is even more important to understand that every App Service plan can support multiple App Services. We rarely want to buy one physical server for each application we need to host, and App Service plans are no different. If you have, for example, three small services to host, you can place all the services into a single plan to save money.


With today’s microservice oriented architectures it is important to control the density of your service deployments to make the best use of your money. You might use metrics to discover that only one of the three services you deploy comes under significant load, and instead of using a single plan, it is better to place the busiest service on a dedicated plan. A dedicated plan allows the service to scale in and out independently of the other two services.

Plans and Deployment Slots

It is also important to understand that apps in deployment slots will execute on the same plan as their associated App Service. Keep this in mind if you ever use a deployment slot to deploy a service for load testing. The load test will impact the same memory, CPU, and other resources used by the production deployment – not something you want to happen.


What’s In a VM?

Once you think of a plan as the virtual machine used to host your apps and services, you start to wonder what the virtual machine looks like. What software is installed? What web server will the application use? Is there a place on the file system where you can write temporary files?

When you create an App Service Plan, you can select from a Windows plan, a Linux plan, or a container plan (where a custom container can run on either a Linux or Windows machine).


A Windows plan gives you a Window Server machine with IIS available to host your application. There is also a plethora of other software installed, including NodeJS and two major versions of Python. If there is a component or framework your application needs that the machine doesn’t include by default, you can use App Service Extensions to extend the machine with new software. Extensions are popular for installing preview versions of .NET Core, for example.


Originally, Windows based app service plans were intended to run any and all web applications regardless of the technology stack. Support exists for everything from ASP.NET to Ruby. However, some technology choices, like Ruby, will have an easier time on Linux.

If you use a Linux based App Service plan, you also select a built-in container image as the base for your deployment. Each runtime is optimized to work with a specific technology. The Python image, for example, includes a specific Python version as well as the gunicorn web server, which is popular for Python development.


If you need to customize a Linux VM, the best approach is to use a custom Docker container instead of the built-in containers. A custom container can also work to customize a Windows plan, since containers are supported on both Linux and Windows plans. With custom containers, you can use a Dockerfile to install and configure any software dependencies or file system layouts your services require. You can place the image into a public container repository like DockerHub, or in a private registry like Azure Container Registry. Best of all, it is easy to configure an App Service to update whenever a new version of the container image appears in the registry. Deployment then, is as easy as pushing a new image to your registry.


The important take away from these series of articles is how App Services are not some abstract service that mysteriously hosts your application. App Services are a managed platform that give you virtual machines you can tailor for your application’s needs. In the next article, the last in this series, we’ll talk about some of the diagnostic options for Azure App Services.