Understanding Azure App Service Plans and Pricing

Published on
Reading time

May 2024 Note: a few things have changed in App Service Plans and Pricing recenty and I have an update to this post pending and will have it published soon!

Like many things in Azure, Azure App Service has a multitude of consumption options available that can sometimes make it hard to determine what option suits your use. This post was updated in November 2020 to reflect the current state of services. Any questions? Leave a comment!

In this post I'm going to walk through App Service, and for simplicity's sake, I'm going to stick to deploying just Web Apps.

So, what do we have available and how does it best fit what I want to do?

Firstly, you can deploy more than a single app into a Plan at no additional cost. New apps will be deployed alongside existing apps and share the resource allocation available in Plan Tier (this is how the old Azure Websites worked, so not much has changed here).

Beyond this there are nuances that it's worth exploring.

2019 update

The App Services team has published a useful filtering page that shows the full set of service tiers and features, along with a detailed list of restrictions.

Probably the biggest change since this post was originally published is the introduction of Linux and Container support. If you have solutions that can run on Linux or in a Container then it's worth looking at using Linux in place of Windows - you get the majority of the features the Windows instances do at a slightly lower price point.

2020 update

There is a new kid on the block - Premium v3. This new plan brings updated VMs under the hood, Windows Containers support and improvements in Azure networking integration. Another great change is access to cost savings via dev/test pricing and Reservations. Alongside the Premium v3 Plan there is also a new App Service Environment (ASE) v3 offer which utilises a simpler deployment footprint resulting in cost savings. Check out the details below.

Free Tier (F1)

Charge Model: free

Does what it says on the tin - gives you some Azure App Service capacity for free.

Your application runs on shared infrastructure. You can deploy up to 10 apps into a single Free Plan.

As with anything free, there is a trade-off - with this tier you get a maximum of 60 minutes CPU daily, with 1 GB RAM, 1 GB disk space and no SLA. You also can't use a custom domain, SSL or run 64 bit solutions here.

2019 update: this tier doesn't offer Linux or Web Apps for Containers support - you need to run on the Basic tier to access these capabilities.

Suitable for Proof-of-Concepts (PoCs) or simple dev/test. Recommendation to avoid for production use as there is no SSL or support (SLA) in place.

Shared (D1)

Charge Model: fixed per-hour charge.

Provides you with a small step up from the Free tier, but still not really aimed at production workloads.

Your application runs on shared infrastructure. You can deploy up to 100 apps into a single Shared Plan. The Shared tier supports only 32 bit applications that can use CPU cycles for up to 240 minutes per day.

2019 update: this tier doesn't offer Linux or Web Apps for Containers support - you need to run on the Basic tier to access these capabilities. There's a new Shared tier in preview at time of writing - I'll update this post once it is Generally Available.

While still not backed by an SLA, this tier may be more suited to simple non-critical workloads (such a smartlink redirect hosts) where they may only be used occasionally during any 24 hour period and that some service disruption isn't impactful on anyone. A 302 redirect doesn't burn many of those 240 minutes ;).

Basic (B1 - B3)

Charge Model: per-hour charge based on number of instances.

For example: B2 tier running Windows (in USD in US West) with 3 instances - 3 x 0.15/hr=0.15/hr = 0.45/hr

This is where App Service Plans meets production workload hosting. You are now running on dedicated instances and benefit from a 99.9% availability SLA. You can deploy unlimited apps into a single Basic Plan (though you'll likely hit resource limits before hitting "unlimited" ;) ).

You also have access now to manual scale-out (increase number of instances) up to a maximum of three instances and scale-up (shift from B1 - B2 - B3 tiers) options. Traffic is automatically balanced between your instances.

2019 update: this tier is where Linux and Web Apps for Containers support starts.

If you have simple containerised workloads and don't want or need the complexity of an orchestrator like Kubernetes then Web Apps for Containers is a great place to start.

Limitations at this tier includes support for only a single SSL certificate per Plan. If you can leverage SNI then you can run multiple web apps on SSL. If not, it's one app per Plan then!

If you need to connect to a private Azure network or use Deployment Slots then this tier is also not suitable for you.

The Basic tier is a good starting place if you're bringing an existing app into App Service, particularly if your current application is unlikely to support load balancing or auto-scale or does not require substantial resources to run.

Standard (S1 - S3)

Charge Model: per-hour charge based on number of instances.

For example: S3 tier with Windows (in USD in US West) with 5 instances - 5 x 0.40/hr=0.40/hr = 2.00/hr

Standard tier provides everything Basic does (the instances are the same apart from increased disk space), but there are a few add-ons that make this a serious proposition for modern apps. Your availability SLA increases at this tier to 99.95%.

You gain additional SSL support (both SNI and IP address), additional scale-out support (up to 10 instances with auto-scale included), plus you can use automated daily backups, Deployment Slots and Azure Traffic Manager for geo-availability. If you want to use private data sources in Azure in your applications you can also use VNet integration with this tier to access them.

Slots (or "Staging Environments"), and how they apply when you deploy multiple apps into a plan are a bit of grey area too. Let me clarify that the "5" listed for this Tier means you get up to 5 Slots per deployed Web App (note each Slot shares the same pool of resources as your live site.. so don't do stress / performance testing here ;) ).

Premium v2 (P1v2 - P3v2)

Charge Model: per-hour charge based on number of instances.

For example: P1v2 tier with Windows (in USD in US West) with 10 instances - 10 x 0.20/hr=0.20/hr = 2.00/hr

2019 update: the biggest change here since my original post is the new v2 instances based on more modern underlying compute which offer better performance and pricing than the old v1 instances. Also changed is that the new Premium tier no longer supports App Service Environments which have now moved to their own dedicated tier which I'll cover in its own section.

Beyond what Standard gives you, you now get support for up to 20 instances along with 50 daily backups and 20 slots. Your instances have higher spec CPU with more RAM and storage than at the Standard tier. The pricing at this tier is also not that much different from Standard, but if you need just that bit more grunt to run your application then a step up from Standard to Premium is worth considering.

This offer remains available to support existing deployments, though if you're looking to use Premium for a new workload you should look at what's next!

Premium v3 (P1v3 - P3v3)

Charge model: as per the v2 Plan though you now have access to 1 and 3 year reservation pricing which brings costs down. You can now also use v3 Plans in dev/test subscriptions.

For example: P1v3 tier with Windows (in USD in US West) with 10 instances - 10 x 0.335/hr=0.335/hr = 3.35/hr

(Once reserved pricing is public I'll update this with an example).

I'm classifying this separately to the v2 Plans because the v3 Plans provide you with features that will not be available in v2. As I mentioned right at the top of this post, the v3 Plan includes newer CPUs and more memory per instance. You also have Hyper-V Windows Container support which makes this Plan perfect for ASP.NET or other Windows Web Application modernisation. Other capabilities like backups, etc, remain as per v2 Plans.

Isolated Service Plan (I1 - I3)

2019 update: this is a completely new tier since my original post!

Charge Model: fixed per-hour cost with an additional per-hour charge based on number of instances.

For example: I1 tier with Windows (in USD in US West) with 10 instances - 1.546/hr+(10x1.546/hr + (10 x 0.40/hr) = $5.546/hr

Prior to the Premium v2 offering if you wanted to use App Service Environments (ASEs) you provisioned a Premium-tier Plan. Clearly not everyone who wanted access to the performance or scale of Premium necessarily needed (or wanted) an ASE, so the Isolated Service Plan tier was created so people could specify it as a way to setup an ASE.

The compute for Isolated Service Plans is the same as the Premium tier, however you have several advantages over Premium when it comes to scale-out (up to 100 instances, with more available via support request), private network access and isolated hosting. Some high-compliance industries such as banking require separation of workloads from other customers and an ASE provides this guarantee. You can also access on-premises resources from within an ASE via VNet connectivity over a VPN or ExpressRoute.

You will select this tier if you have a compliance-driven environment but want to use public cloud PaaS, or if you have substantial scale-out needs. I'd definitely recommend reading the documentation and watching some of the videos on ASEs (specifically the "v2" flavour which runs on Isolated Plans) to understand the benefits you get for the money you're paying.

App Service Environments v3

At time of update in November 2020 this preview isn't yet available for use, but it promises some great improvements for those needing ASEs. The engineering team has rebuilt the Premium infrastructure that powers ASEs v3 from the ground up which has resulted in a much simpler and flexible deployment footprint for ASEs. This means that customers can recognise a substantial cost saving versus the previous generation of ASEs.

Once there is more public information around this Plan I'll update this post with an example. In meantime you can read an overview of what's coming on the announcement blog.

Similar to the v3 Premium Plan the new v3 ASE isn't designed to replace the ASE v2, but if you are looking to start using ASEs then you should consider v3 as your first port of call.


As you can see, there is a lot of flexibility available when hosting Web Apps in App Service. If you have lots of small web apps that can coexist on the same machines (a fairly typical model in traditional web hosting) then you should look closely at App Service as a solution to your needs in Azure.

Finally, Microsoft has even developed some tooling that can even help you figure out how to move - check out https://appmigration.microsoft.com/.

Happy days! 😎