In the Part 1 blog post, I have shown configuration of auto scale of 2 auto-scale profiles. I will show the operation of scaling out and scaling in.

Upon a load test to simulate high load on the app service to trigger the auto-scale, here are the timelines and operations of the auto scale out and in.

1. 6:56:10 PM
   Initiated Visual Studio load test for 15-minute duration.
2. 7:11:40 PM
   Load Test Ended
3. 7:13 PM
   Auto scale out is triggered and receive email notification
   “Autoscale successfully started scale operation for resource ‘AppServicePlan” from capacity ‘1’ to capacity ‘3’”
   Note this scale rule is from the 2^nd
4. 8:31 PM
   Auto scale in is triggered and receive email notification
   “Autoscale successfully started scale operation for resource ‘AppServicePlan” from capacity ‘3’ to capacity ‘2’”
   Note this is coming from the default profile.
5. 8:37 PM
   Auto scale in is triggered and receive email notification
   “Autoscale successfully started scale operation for resource ‘AppServicePlan” from capacity ‘2’ to capacity ‘1’”
   Note this is triggered after the configured 5-minute cool down period and is from the default profile.

Azure Monitor > Metrics (preview)

You can see that the average during the duration of the test was 34.7%. However, since both scale rules or for 5-minute window, you can see that a 50% average is possible during this window.

Azure App Service Plan > Activity Log

Go to the activity log you can see the scale up and scale down operations and its time stamps.

Auto Scale Run History

Go to the Scale Out blade and click Run history to see a graph of the scale out and scale in operations.

For some reason the scale out operation time lines do not match the timing of the email notifications and activity logs. The scale out occurred much later and appears to have taken much longer. According to activity logs, the scaling out and in durations complete almost immediately. But there is word of caution in the screen shot regarding the accuracy of the observed instance count. So I recommend referring to the activity log for accurate timing of events. 

Scale Rule vs Scale Condition

A point of clarification. I find that the scale condition is based only on its date and time schedule and does not include any other scale rules in other profiles. Based on my auto scale settings, I assumed that after scaling up from 1 to 3 instances, my default profile will very soon trigger its scale in rule to decrease the count when the CPU average < 5%. This is not the case. I have to wait until the 2^nd profile’s schedule expires and then the default profile scale rules will take effect. The profile expries at 8:30pm each day. As such, the default profile’s scale in rule triggered at 8:31pm

Final Remarks

With the advent of cloud computing, its unique characteristic is its elasticity. The auto-scaling shown is an implementation elasticity to respond to dynamic and variable demand. So, I would highly recommend in being knowledgeable in auto-scaling at least one of Azure app service, virtual machines, cloud services or other scalable Azure services. And therefore, take advantage of what cloud computing uniquely has to offer and express this value in solutioning among your colleagues and stakeholders.