Scaling In Azure App Service - Almost All You Need To Know (2024)

In terms of web applications, underlying infrastructure plays a vital role in coping with application performance, traffic surges, complex logic, and long-running processor execution times. It is one of the most difficult jobs to calculate the specifications in terms of infrastructure for web applications, whether it is public-facing applications or for a particular company.

In many cases, there is a high chance that there will be a requirement to upgrade infrastructure specifications after a certain threshold, or maybe resources are not utilized properly. This is another hassle for developers, DevOps engineers, or even for management to upgrade those resources. It may results in application downtime, unstable or sometimes modifications in code level, as well as being quite expensive overall.

One of the key advantages of cloud computing is the capability to scale the solution based on demands.

Azure App Service gives various flexible choices in terms of scaling.

Scaling in Azure App Services

Azure App Service is one of my favorite services in terms of hosting web applications because of numerous reasons, of which scaling is one of my favorites that I use frequently.

Azure provides several flexible options to easily scale your apps either horizontally by adding multiple instances of those solutions or vertically enabling to add memory, CPU disk to your existing instances.

Scaling Options: Scale-Up vs. Scale-Out

Scale-up and scale-out are two primary workflows for scaling.

Scale-Out (Horizontal scaling)

It is basically adding multiple instances of the application that runs in your app. In other words, it increases the number of VM instances up to 30 depending upon your pricing tier. However, in an Isolated tier, we can further scale up to 100 instances based on our requirements. Additionally, we can do a scale-out count manually or set it to auto-scaling based on some rules.

We can do scale-out from the Azure portal, as shown below:

Autoscale is a built-in feature that helps applications perform their best when demand changes. You can choose to scale your resource manually to a specific instance count, or via a custom Autoscale policy that scales based on metric(s) thresholds, or schedule instance count which scales during designated time windows. Autoscale enables your resource to be performant and cost-effective by adding and removing instances based on demand.

Select Scale-out from the left navigation, then we can choose either manual and set instance number as per our requirements or auto-scale out based on some rule as shown below:

We have to auto-scale the setting name with the resource group name. We will have some more options like scale mode, rules, instance limit, and schedule. This is how we can do horizontal scaling (i.e., scale-out in Azure App Services.)

Scale-up (Vertical scaling)

In this scaling option, we can modify the instance power in terms of CPU, memory, disk space which directly impact the cost. This scale-up is done by changing the pricing tier of the app service plan. Additionally, based on the pricing tier, different useful features are available with the azure app service like custom domains and certificates, staging slots, autoscaling, instances, daily backups, and many more.

Scaling is quite easy to do in azure, I prefer from the portal, portal.azure.com.

Simply log in to the portal, open your app service then you will see the following options for scaling:

In the scale-up, we can see the distinct categories: Dev/Test, Production, and Isolated.

Dev/Test

As the name suggests, this category is used for development and testing purposes of the applications with Azure App Service.

There are five separate pricing tiers in the Dev/Test category, as shown below:

F1 (free one), D1, B1, B2, and B3

We can see from the above illustration that the resources as well as tentative cost per month based on these pricing tiers.

Another important point to notice is that we can see the included features and hardware after selecting each tier, as depicted below:

D1 Pricing Tier

These service plans are using the same Azure VMs as other apps, so some apps may belong to other customers.

There is no SLA provided for this service plan and is metered on a per-app basis.

Basic Service Plan (B1, B3 and B3)

This plan is for low-traffic applications where we don’t need auto-scaling and traffic management features. Built-in network load balancing support automatically distributes traffic across instances.

B1 Pricing Tier

Included Features

Hardware

B2 and B3 have the same features as B1, however, hardware contents are different.

B2 Hardware

B3 Hardware

Premium Service Plan

This service plan is intended for enhanced performance with a faster processor, SSD storage, and double memory-to-core ratio compared to standard.

Premium V3

Faster processor, Hyper-V virtualization, and support for VNet connectivity P1, P2, P3, P1V2, P2V2, P3V2, P1V3, P2V3, and P3V3 are available pricing tiers for this option with the following specifications