The term autoscaling can have several meanings including scaling out (adding additional instance), scaling up (adding more resources to an existing instance) and scaling down (removing resources from an existing instance). In Azure this is explained at In this three part blog post series, my goal is to explain what the current state for autoscaling is in Azure, System Center and WAP. For background on Azure and how System Center works with the cloud check out

In this first part of the series, I will look into autoscaling and how it works in Azure. The three parts for this blog series are listed below.

Part 1: Autoscaling in Azure [this blog post]

Part 2: Autoscaling in System Center

Part 3: Autoscaling in WAP

In this blog post we will show examples for how autoscaling can be used in PaaS and IaaS.


Autoscaling in PaaS:

Out of the box Azure does not currently provide scaling up or scaling down but scaling out is available for anything in PaaS. Applications written for PaaS can be autoscaled. Azure deploys the applications into VMs as needed. Since these applications are in PaaS we do not need to maintain the VMs (IE patching, anti-virus, etc). As a simple example of how PaaS works let’s focus on a website. Websites work well in a scale out scenario as they can adjust due to unpredictable usage patterns and they are not a monolithic application which needs to scale up during periods of high utilization.

Oftentimes the best way to learn something is just to give it a try to see how it works. For this blog post we will create a simple website in Azure and show how this can be configured to for scaling. To start this process we begin by creating a website in Azure.

Microsoft includes pre-built examples, such as the bakery example shown below.

Once this website is created, we need to configure it to an options which will allow autoscaling. Once the website is ready we can verify that it’s online by browsing to the website (as shown below).

This website can be changed from free to Standard or above which allows configuration for autoscaling.

Once the website has been configured as standard we can now configure schedule times for the website. For this example I am configuring different settings for day and night as shown below.

Setup a schedule


With autoscaling I can configure instance counts based on usage (the example below is based upon CPU utilization exceeding 80% during the day, and having between 1 to 3 instances during the day).


The other parts of the schedule can be configured differently – the example below shows the night schedule configured to only run one instance.

Using the example above it’s easy to see how a website could be configured to use autoscaling within Azure.

Autoscaling in IaaS:

Out of the box Azure does not currently provide scaling up or scaling down for IaaS but scaling out is available for IaaS. John Savill has provided an excellent explaination of Azure Auto-Scale with IaaS in his walkthrough available at The second part of John’s video (from minute 9 – 14) shows the configurations required in IaaS to use autoscaling in Azure.

I utilize a virtual running in Azure IaaS to provide functionality which I cannot run locally on my Surface 2 RT (discussed at To take advantage of the scaling functionality available for IaaS I shut down my existing virtual and made a copy of it. I added these two virtuals into an availability set which includes both of these IaaS virtuals (shown below).


The schedule is configured to run one instance of the VM during the day and during the night it is configured for zero instances of the VM. The graph below shows how the virtual count changes between 1 and 0 depending on the time of the day which decreases the total usage of my Azure subscription by shutting down this virtual during non-work hours.


Summary: Autoscaling out is a function which is available out of the box in Azure for both PaaS and IaaS. Additionally, scripting can be used to automate autoscaling up and down for resources in Azure. In the next part of this blog post I will discuss autoscaling from a System Center perspective.

Thank you to Tony Nguyen and John Savill for their excellent insights into this topic!