Deploying Virtual Machine Scale Sets

​

What is scaling in Azure?

• Vertical scaling (scale up / scale down): increase or decrease the capacity of a single resource (for example, changing a VM to a larger or smaller size). This can be limited by the maximum instance size and may require downtime.
• Horizontal scaling (scale out / scale in): change the number of instances. Adding instances is scale out; removing instances is scale in. Virtual Machine Scale Sets provide horizontal scaling.

​

Virtual Machine Scale Sets (VMSS) overview

• Integration with Azure Load Balancer and Application Gateway.
• Autoscale by schedule or metrics (CPU, memory via diagnostics, custom metrics).
• Uniform orchestration: all instances are identical (same image and size).
• Flexible orchestration: supports mixing VM sizes and types within a scale set.
• Distribution across Availability Zones for higher availability.
• Default maximum instances per scale set: 1,000 for most images (some scenarios like managed images or specific SKUs may have lower practical limits—commonly around 600).

​

Deploying a VMSS from the Azure portal — step by step

1. Basic settings: select subscription, resource group (RGHA / rg-ha-01), scale set name (VMSSHA01 / vmss-ha-01), region and orchestration mode. Choose the OS image and VM size.

2. Spot instances: if you want to use Spot VMs to save cost, configure eviction policy and max price. In this demo, Spot instances are not used.

3. Disks: choose OS disk type (Standard SSD in this example) and configure disk encryption or size as needed. The VMSS workflow will present similar disk options as for single VMs but applied across the set.

4. Networking: choose the virtual network (VNet) and network interface settings. Decide whether instances get public IPs (not recommended for scale set instances) or remain private behind a jump host or bastion.

5. Scaling tab: configure autoscale behavior — initial instance count, min/max instances, and autoscale rules. For example, use CPU threshold rules to add or remove instances automatically.

• Rule: If CPU usage remains above 75% for 10 minutes, increase instance count by 1.
• Rule: After a cooldown period, if CPU drops to 25% or below, decrease instance count by 1.
• Set minimum and maximum instance counts to enforce capacity boundaries (for example min=1, max=10).

6. Advanced options: enable features such as scaling beyond 100 instances and strict distribution/spreading across Availability Zones.

7. Review + Create: validate settings and create the scale set. Azure will provision the initial instances and the VMSS resource.

​

Verifying instances and connecting

# SSH into jump host (public IP)
ssh kodekloud@20.124.250.11

# From the jump host, SSH to the VMSS instance's private IP
ssh kodekloud@10.0.0.6

​

Generating load to test autoscale

sudo apt update
sudo apt install -y stress

Usage: stress [OPTION [ARG]] ...
 -t, --timeout N      timeout after N seconds
 -c, --cpu N          spawn N workers spinning on sqrt()
 -i, --io N           spawn N workers spinning on sync()
 -m, --vm N           spawn N workers spinning on malloc()/free()
 --vm-bytes B         malloc B bytes per vm worker (default is 256MB)
Example: stress --cpu 8 --io 4 --vm 2 --vm-bytes 128M --timeout 10s

sudo stress -c 2 -t 600 -v

CPU[||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
Mem[|||||||||||||||||||||||||||247M/894M]
Tasks: 42, 36 thr; 1 running
Load average: 1.70 0.63 0.28
Uptime: 00:16:08

  PID USER      PRI  NI VIRT   RES  SHR S CPU% MEM%   TIME+  Command
 2445 root       20   0 3864   96    0  R 50.0  0.0  0:47.52  stress -c 2 -t 600 -v
 2444 root       20   0 3864   96    0  R 50.0  0.0  0:47.52  stress -c 2 -t 600 -v

​

Monitoring autoscale events

​

Best practices and summary

• Bake your base image with the application installed and use it for VMSS to shorten provisioning time.
• Put a load balancer or application gateway in front of the scale set so traffic is distributed and instances can be health-probed.
• Configure autoscale rules with sensible thresholds, cooldowns, and min/max instances to avoid rapid scale churn.
• Prefer Uniform orchestration for identical workloads and Flexible for mixed VM families or single-instance VMs in a group.
• Use a jump host or Azure Bastion for secure access to private-only VMSS instances.

​

Links and references

• Azure Virtual Machine Scale Sets documentation
• Azure Autoscale documentation
• Azure Load Balancer overview