Hosting an Azure App Service from a cost perspective

In essence, it’s quite simple to host an App service in Azure. When you want to host an App Service you have a big selection of options to choose from. But how do you know which App Service is best for your company to host your app, also from a cost perspective Sometimes it can even be beneficial to let developers work on a legacy app in order to let it run on a different platform. Let’s check out why.

Before diving into the options Azure provides, we first look at the application you want to host in Azure. What I usually do is first examine the platform which is needed to host the application.
You have the following options in Azure:

  1. Windows hosted
  2. Linux hosted

Now the price you pay in Azure starts with the platform you use to run your App. For example, running a

My parameters for these calculations are:
– Production environment
– Hosted in East US region
– Running for an entire period of 31 days
– Only 1 instance

Windows hosted

When you use the Azure Portal and you configure a default web app, you will see that it default is fixed on the P1V2 which is pretty expensive if you would let it run for a month.

Why choose Windows hosted App services?
– You have a legacy web application that runs on .Net Framework
– Your legacy web application is running on IIS-specific settings
– You have old Webservices that run WCF and/or old SOAP (ASMX) services
– You want to run Background tasks using WebJobs in Azure App Service (batch files, PowerShell scripts, etc)

Besides the points above there should be, in my opinion, no reason why you should run your web app on a Windows-hosted service because it’s really costly.

Linux hosted

Now let’s take a look at Linux-hosted P1V2. This is almost half the prize of a Windows hosted.

All modern .Net applications are able to run on Linux. Starting from .net Core until the latest .Net version, Microsoft provided full Linux support. As you can see, based on the pricing, it can really be beneficial to port your .Net Framework application to .Net Core or later.


So lets us take a closer look at the costs:
F1 and D1 are free or are really cheap. These are the Basic and Shared tiers. Those are being used for development purposes only.
B1 is the basic tier for applications that are low in traffic and don’t need features like auto-scale and traffic management. Custom domains are supported and you can use Web App containers if you’re using the Linux platform. Also from this tier, you can start using VNet integration.
S1 tier is becoming really production worthy. Auto-scaling / traffic management is supported.
P1V2 tier is basically the same as S1, but with far better performance. Your production app runs on better hardware to really give your application a boost. It also has al the benefits of the S1 of course. But look at the pricing difference between Linux and Windows Platform for the S1 en P1V2 variants.
P1V3 is again an upgrade of hardware. This includes the latest HyperV technology. Also, you can have some discount if you are going to reserve some processing power over a time period of 1,2 or 3 years. I can really recommend this if you don’t expect big changes in your application traffic over a period of time. Also, Windows and Linux containers are fully supported, but code-deployment options.
Isolated (ISO) All the tiers above are on shared hardware within the Azure data centres. You also have the option to run your own isolated VNet and Apps on dedicated hardware. Which is very secure, but really costly.


Keep expenses under control

As you can see you have quite some options to choose from. In the above calculations, we only looked at 1 instance running. If the traffic on your application increases, and you have auto-scaling enabled, prices can really build up without any warning. Luckily in Azure Portal, you also have the ability to set up a budget for one or more resource groups. Azure then automatically notifies you if your registered budget is exceeding.