Configuring Virtual Machine Scale Sets with Autoscaling

Overview and What You Will Learn

In this lab, you will create a Virtual Machine Scale Set, configure an autoscale rule that adds instances when CPU load rises, and simulate load to watch the scale set actually add capacity automatically, then remove it again once load drops.

Why This Matters in Production

During a flash sale, a CRED-style fintech app needs to handle a sudden ten-fold spike in traffic without the engineering team manually launching new VMs at 2 AM, and without paying for that same peak capacity to sit idle for the other 364 days of the year. A properly configured scale set handles both sides of this problem automatically.

Core Principles

A Virtual Machine Scale Set manages a group of identical, load-balanced VMs as a single unit. Instead of manually deciding when to add or remove capacity, an autoscale rule watches a metric and adjusts instance count on its own.

The scale set's min, max, and current instance count define the boundaries autoscaling operates within - it will never scale below the minimum or above the maximum, regardless of how extreme the metric readings become.

Detailed Step-by-Step Practical Lab

1. Create a Resource Group:

2. Create a Virtual Machine Scale Set with an initial instance count of 2:

3. Confirm both instances are running:

4. Create an autoscale profile with a minimum of 2 and a maximum of 6 instances:

5. Add a scale-out rule that adds one instance when average CPU exceeds 70% for 5 minutes:

6. Add a scale-in rule that removes one instance when average CPU drops below 30% for 5 minutes:

Note

Scale-out and scale-in rules are configured independently and often use different thresholds on purpose. A wider gap between the two (like 70% out, 30% in) prevents the scale set from rapidly oscillating instances up and down when load hovers near a single shared threshold.

7. Simulate CPU load on the instances (using a tool like stress installed on the VM) and watch the instance count grow:

8. Clean up:

Production Best Practices & Common Pitfalls

Common Mistake

Setting the scale-out and scale-in thresholds too close together, like 60% out and 55% in. When load hovers naturally around that range, the scale set can rapidly add and remove instances back and forth, wasting time and money on constant scaling activity instead of settling into a stable state.

Tip

Set a Cooldown period on autoscale rules so the scale set waits a reasonable amount of time after a scaling action before evaluating whether to scale again. This prevents overly aggressive back-to-back scaling decisions based on brief, temporary metric spikes.

• Scale sets update by rolling out a new VM image, not by patching running instances individually. Build your application updates into a new image version and let the scale set roll it out, rather than trying to manually update every running instance.
• Instance count boundaries (min/max) should reflect real cost and capacity planning, not arbitrary round numbers. A max count set too low can silently cap your application's ability to handle a genuine traffic spike.

Quick Reference & Troubleshooting Commands