skip to Main Content

Azure App Service – Web Apps

One of Azure’s most popular services is App Service Plan. App Service Plans can serve many purposes, including solutions around API, Mobile and Web apps. Today we will explore the web apps offering, which is a compelling choice to use for building new cloud-native web applications.

Azure App Service Plan Overview

As we said in the intro the core component of web apps is the App Service Plan, it cannot exist without it. This is where you define the compute, region, operating system (Windows or Linux) and pricing tier of your project needs. There are a couple of important notes for some key areas worth mentioning.


Obviously, this is the geographical location of where your service will run. Naturally, you will want to keep this close to your user base consuming the application. You can build out some complex designs here where you stack other Azure services, such as Azure Front Door (Layer 7 HTTP/HTTPS layer anycast protocol) to build a truly global scalable web application.


There are many tiers to choose from including Free, Shared, Basic, Standard, Premium, PremiumV2, PremiumV3 and Isolated.

These vary massively and I encourage you to make sure the type fulfils your need at the cost point you desire. For example, if there is a pre-requisite to only run on dedicated compute and lock the environment via VNET integration then you have no choice but to use the isolated tier.

To summarise:

  • Shared compute: Free and Shared, the two base tiers, run an app on the same Azure VM as other App Service apps, including apps of other customers. Your app receives CPU minutes on a shared VM instance and cannot scale-out. These tiers are intended to be used only for development and testing purposes – do not use for production.
  • Dedicated compute: The Basic, Standard, Premium, PremiumV2, and PremiumV3 tiers run apps on dedicated Azure VMs.
  • Isolated: This tier runs dedicated Azure VMs on dedicated Azure Virtual Networks thus giving complete network isolation and enhanced security.

Let’s look visually

It is probably easier to visualise the relationship of tiers and compute via the Azure Portal. Let’s look at the different options.

Under the settings of an App Service Plan, you will see options for scaling. This is where you will find the tiers:

Azure App Service Plan Menu

Azure App Service Plan Tiers

As soon as you select “Production” you will see a selection of S and P based tiers. Within the tiers, the compute resources are stated but you also get additional features shown below:

Additional features

For isolated setups, the below is shown via an App Service Environment (ASE).

Isolated Setups

Create Azure App Service Environment

This is the true isolation and dedication of hardware. The ASE is normally deployed on VMs that are provisioned on a multi-tenant hypervisor. If you need to deploy on dedicated systems, including the hardware, you can provision your ASE onto dedicated hosts. Dedicated hosts come in a pair to ensure redundancy. As you can tell, this is all dedicated so it is usually deployed to your virtual network so you can expect to integrate other resources within that virtual network too – that is if it is required. The downside of this is cost, something you need to consider before moving to this design.

Talking about costs, from a design perspective you can potentially save money by putting multiple web apps into one App Service plan. However, keep in mind that apps in the same App Service plan all share the same compute resources so be careful of the noisy neighbour effect. It is best advised to consider isolated apps if:

  • You know that a key app will be resource-intensive.
  • You want to scale the app independently away from other apps you may have within the service plan.


Environments and Slots

The goal is to follow your DevOps / branching processes and have the setup below.

Environment setup

This can only be done if you utilise slots via the standard or premium plans shown earlier.  The idea of using slots is to carve out environments for application code releases, for example, a staging slot. You can use this area to deploy and test new code and once successfully tested you would switch out from staging to production (or another layer if needed). If there was an issue, then it is easier to switch back to a previous slot.

As you can see this idea of swaps and slots is useful for those DevOps practices where you can build out CD (Continuous Delivery) pipelines to automatically deploy to staging then to production based on the branching strategy you use i.e., a push on main / master.

As a side tip, if your App Service Plan is using over 90% of available CPU or memory during a deployment, the underlying virtual machine may have trouble processing your deployment. When this happens, temporarily scale up your instance to perform the deployment.

Alternatively, you can do manual deployments, which includes the following methods:

  • Azure CLI.
  • Zip-deploy.
  • Directly from Visual Studio.
  • FTP

Azure CLI deployment is very common, below shows the relevant steps you would need to do from the command line.

Login to Azure
az login

Confirm that your web app exists in Azure
az webapp list –resource-group Yourwebappresourcegroup

CD to where your local files are being built
cd F:\Web\API\

az webapp deployment source config-zip –resource-group Yourwebappresourcegroup–src –name <name of your app>



Being a cloud-native technology, you have the possibility to scale up and out the App Service Plan. When you scale up, we are saying that we can assign more cores, memory and disk space – all the metrics you would expect. This is basically moving up a pricing tier. This is completely different to the idea of scaling out.

When we scale-out, we are adding more virtual machines to run the app (horizontally), up to a maximum of 20 instances. This goes very well with the auto-scaling feature. For autoscaling, at a high level you need to create an auto-scale job with an associated rule to scale by, so that upon checking if it has crossed the configured threshold for a scale-out, it will occur (or a scale in request). A rule could look like If CPU > 90%, scale-out by 1.


Azure App Service – Web Apps

When you build a web app in Azure it responds over HTTP on port TCP 80/443, they offer many runtime languages, so it is flexible and not locked down to a specific language.  Let’s look at a basic example of how we can deploy to Azure.

Let’s look at a basic example within Visual Studio Code, below is a snippet.

Visual Studio Code snippet

I navigate to the Azure section of Visual Studio Code and go through the process of creating an Azure Web App as shown below.

Create Azure Web App

Work your way through the settings which include concepts we have covered in theory such as the region, operating system and tier for the App Service Plan.

Web App Settings

Below I define a resource group as you would expect.

Define Resource Group

I then select the .NET core version I would like.

.NET Core Version

Then I start building the App Service Plan details.

Build Azure App Service Plan details

Build Azure App service plan details 2

Build Azure App Service plan details 3

I decide to make some application code changes then redeploy to Azure (I deploy directly from Visual Studio Code, if you remember this is one of the manual ways you can do it).

Redeploy to Azure 1

Redeploy to Azure 2

Redeploy to Azure 3

Redeploy to Azure 4

If you click browse, it will take you to the web app hosted in the cloud.

Web App hosted in the cloud

You can see the relevant information/metrics within the Azure Portal regarding both the web app and App Service Plan itself.

Azure App Services

You will have a wealth of information at your fingertips.

Web App Information 1

Web app information 2

In Closing

So, you can see the benefits of running such applications in the cloud. I no longer have to worry about the underlying hardware, meaning I no longer have to be concerned about patching both the hardware and operating system that the code runs on.

Microsoft generally deploys new runtime versions in a side-by-side strategy so you may have to manually upgrade to that newer version. An example of upgrading via Azure CLI would look like this:

az webapp config set \ –net-framework-version v4.7 \ –resource-group <groupname> \ –name <yourappname>

If the version that you are currently running on is announced for deprecation, you need not worry as Microsoft will state a removal date so you can work on a migration path for your apps.

If you are in need of consultancy before starting development or are looking for a fully outsourced custom software development partner, check out our work in Azure or get in touch.

Azure App Service – Web Apps References

Post Terms: Azure App Services | Cloud-native web apps | web apps

About the Author

Arun Sirpal, writing here as a freelance blogger, is a four-time former Data Platform MVP, specialising in Microsoft Azure and Database technology. A frequent writer, his articles have been published on SQL Server Central and Microsoft TechNet alongside his own personal website. During 2017/2018 he worked with the Microsoft SQL Server product team on testing the vNext adaptive query processing feature and other Azure product groups. Arun is a member of Microsoft’s Azure Advisors and SQL Advisors groups and frequently talks about Azure SQL Database.

Education, Membership & Awards

Arun graduated from Aston University in 2007 with a BSc (Hon) in Computer Science and Business. He went on to work as an SQL Analyst, SQL DBA and later as a Senior SQL DBA, DBA Team Lead and now Cloud Solution Architect. Alongside his professional progress, Arun became a member of the Professional Association for SQL Server. He became a Microsoft Most Valued Professional (MVP) in November 2017 and has since won it for the fourth time.

You can find Arun online at:

Back To Top
Contact us for a chat