Azure
Intermediate 15 min read Azure

VMs and Virtual Machine Scale Sets

IaaS compute and how it scales

Azure VMs are IaaS machines with SKU families; VMSS is autoscaling VMs in zones. Know VM sizes, images, disks, and how VMSS + Autoscale keep the right number of machines.

Azure VMVMSSVM sizesmanaged disksAutoscale
Prerequisites: Azure Service Catalog Compute Families
Before we start

What you will learn

  • Choose VM sizes by workload (general purpose, compute, memory, GPU)
  • Explain VMSS, autoscaling and instance orchestration
  • Use managed disks, snapshots and boot diagnostics
In 60 seconds

An Azure VM is a virtual machine with a chosen SKU (family+size), an image, managed disks, and public/private IPs. VMSS is a group of VMs that scales automatically across zones based on load metrics or schedules.

Introduction

What is this?

Azure VMs come in families: general purpose (D, B), compute-optimized (F), memory-optimized (E), storage-optimized (L), GPU (NC/ND) and HPC. A VM uses an image (Ubuntu, Windows Server) and managed disks (Ultra/Premium SSD/Standard SSD/Standard HDD). VMSS (Virtual Machine Scale Sets) is an automatically managed pool: capacity, update policies, autoscaling rules (CPU, custom metrics, scheduled), and health monitoring. Availability sets/zones protect through fault/update domain and zone distribution.

Motivation

Why do you need it?

  • VMs are still the home of legacy/compliance-bound workloads — the fastest migration pattern.
  • VMSS turns scaling into config: rules, min/max instance count, and health polling.
  • Managed disks snapshot, resize and attach cleanly — no manual storage housekeeping.
  • Sizing right the first time is the cheapest cost optimization you'll ever do.
Think about it

Mental model

Imagine

A fleet of taxis vs a self-dispatching fleet

Think of

Standalone VMs vs VMSS

You can call one taxi (provision a VM) each time, or set up a fleet app that dispatches more cars when the queue grows and idles them when quiet — VMSS with autoscale.

Mechanics

How it works

  • The VM size pins vCPUs/RAM/network; SKU family targets a workload class (B-series burstable for dev).
  • Managed disks persist at their own tier; ephemeral OS disks trade resilience for performance.
  • VMSS instance count is the managed dimension — autoscale rules add/remove instances based on metrics and cooldowns.
  • Health: configured probes drive 'unhealthy instances reset/replaced' with the automatic repairs feature.
  • Zones: VMSS can spread instances across multiple zones for zone-level HA.

How VMSS autoscaled across zones.

Autoscale rules
VMSS controller
Zone A/B instances
Load balancer
Scale in
Real world

In production

  • A rendering farm uses GPU-family VMs in a VMSS scaled on queue depth, using Spot instances for elasticity.
  • A Windows estate runs on B-series burstable for dev and D-series for prod, with snapshots for DR.
  • A gaming backend spreads a VMSS across 2 zones with a health probe that replaces failing instances automatically.
Guidelines

Best practices

  • Right-size before scaling; a bigger-than-needed fleet hides in autoscale.
  • Prefer managed disks + disk encryption; enable boot diagnostics.
  • Use VMSS with zones and health probes, not a single oversized VM.
  • Separate OS disk from data disks to snapshot only what changes.
Watch out

Common mistakes

  • Choosing a huge SKU for burst traffic and paying for idle.
  • No autoscale minimum, so traffic collapse scales to zero and cold-starts the fleet.
  • Ignoring cooldown values — rapid scale-up/down cycles look like a sawtooth bill.
  • Forgetting images drift, so VMs become pets instead of cattle.
Root cause analysis

Common issues

Error
Autoscale not scaling out
Root cause

Metric thresholds never cross, or cooldown/evaluation windows are too long

Fix

Watch the metric live, tighten the evaluation period, and check autoscale status in the portal.

Error
Scale set deallocates instances daily at 3am
Root cause

A scheduled autoscale rule fires at a wrong timezone/time

Fix

Review scheduled rules and use UTC consistently.

Error
Snapshots ballooning storage cost
Root cause

Full snapshots taken hourly without differential/incremental

Fix

Use incremental snapshots and set a retention policy.

When things break

Debugging tips

  • VM won't boot: check boot diagnostics and serial console logs, not just status.
  • Scale-in storms: review autoscale cooldowns and the metric the rule watches.
  • Disk full: monitor disk utilization and grow managed disks while attached.
  • VM unreachable: audit NSG inbound rule, public IP and a probe endpoint.
Interviews

Interview checkpoint

Practice

Hands-on lab

Autoscale a VMSS with the CLI
30 min · intermediate
In progress
Objectives
  • Create a VMSS in two zones
  • Configure an autoscale rule
  • Observe instance count changes

Autoscale a VMSS with the CLI

30 min · intermediate

0/5 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/1
1

What does a Virtual Machine Scale Set add over standalone VMs?

Go deeper

Official documentation

Azure — VM sizes
docs
Azure — VMSS overview
docs
Azure — Autoscale
docs