Azure VMSS Complete Guide: Uniform/Flexible, Auto Scale, Rolling Upgrade & Spot Mix

Virtual Machine Scale Sets (VMSS) is the Azure service that auto-scales, auto-deploys, and auto-heals 1-1000 identically configured VMs. Auto Scale adjusts instance count based on demand (CPU utilization or custom metrics), while deployments are standardized via ARM/Bicep templates or a Custom Image. Integrated with Azure Load Balancer / Application Gateway for traffic distribution, VMSS achieves a 99.99% SLA with AZ redundancy. Typical use cases: auto-scaling web tiers, batch processing workers, AKS node pools (internal implementation), and SAP HANA scale-out. VMSS is one of Azure's flagship compute services, enabling far larger and more fault-tolerant operations than standalone VMs.

Uniform Orchestration mode (legacy): every instance has identical configuration (Image, Size, Network), max 1000 instances, with fast Auto Scale. The original VMSS approach, suitable for web tiers and stateless workloads. Flexible Orchestration mode (GA 2021, today's mainstream): each instance is treated as an independent VM resource, allowing mixed VM sizes and Images, max 1000 instances, and more flexible overall. It enables fine-grained AZ redundancy and Fault Domain control, and supports node pools mixing Spot and regular VMs. Flexible mode is recommended for new VMSS deployments, and Microsoft itself recommends migrating from Uniform to Flexible. AKS node pools internally use VMSS Flexible.

Configured via Azure Monitor Auto Scale. Rule types: 1) Metric-based (CPU usage, memory usage, network I/O, etc., the most common), 2) Schedule-based (time-of-day based, e.g., scale up only weekdays 9-18), 3) Custom Metric (Application Insights custom metrics, e.g., queue length, requests/sec). Standard pattern: scale out +1 instance after 5 minutes of CPU > 70%, scale in -1 instance after 10 minutes of CPU < 30%. A Cooldown Period (default 5 min) prevents repeated scaling, and Min / Max Instances set safe bounds. Best practice in production is Min >= 2 (HA guarantee) and Max within your budget ceiling.

Marketplace Image: standard images supplied by Microsoft or OS vendors (Ubuntu 22.04, Windows Server 2025, etc.), with monthly security patch updates so new instances always get the latest patches. Custom Image: organization-built proprietary images (with apps, middleware, and config preinstalled), centrally managed in Azure Compute Gallery (formerly Shared Image Gallery) with cross-region replication and versioning. Benefits include faster deployment (several times faster than Marketplace + Custom Script Extension) and consistency (guaranteed identical configuration across all instances). The modern operating pattern is for new organizations to start with Marketplace Image + Custom Script Extension, transition to Custom Images once stable, and automate image builds via Azure Image Builder in a CI/CD pipeline.

Manual: administrators manually upgrade each instance, most cautious but highest operational overhead. Automatic: upgrades all instances at once, causing downtime, not recommended for production. Rolling: upgrades in batches (e.g., 20% at a time), with the Application Health Probe verifying each batch before proceeding, minimizing downtime. Rolling is the only realistic choice for production: configure Batch Size (20% recommended), Pause Time Between Batches (5-15 min), and Max Surge (temporarily increase capacity for zero-downtime). Installing the Application Health Extension on instances so they can report health to VMSS improves anomaly detection accuracy during Rolling Upgrade.

One of the powerful features of Flexible Orchestration mode. You can mix Spot VMs and regular VMs within a single VMSS using Spot Priority Mix (e.g., 30% regular + 70% Spot). When a Spot VM is evicted, it is automatically replenished with a regular VM. Cost optimization scenarios: 1) stateless web tier with 70% Spot + 30% regular (~50% cost reduction, service continuity even with partial eviction), 2) batch processing with 100% Spot (re-run jobs on stop), 3) AKS node pool mixing Spot and regular. Setting the max Spot price up to pay-as-you-go reduces eviction frequency, striking a balance between cost savings and stability.

Common pitfalls: 1) forgetting to update Custom Images and running on stale OS/apps (automate updates with Image Builder + CI/CD), 2) setting Auto Scale Min Instance to 1 and losing HA (require >= 2 + AZ redundancy), 3) running stateful apps (DB) on VMSS (stateless only; store state in external storage), 4) Rolling Upgrade without a configured Health Probe, so unhealthy instances are deemed Healthy and the service goes down, 5) using Spot VMs for production stateful workloads (eviction causes outages), 6) Upgrade Policy set to Automatic causing service outage, 7) subnet IP exhaustion (a /24 cannot hold 1000 instances), 8) ignoring Custom Script Extension failures (set up alerts on failures), 9) skipping Reserved Instances and ballooning pay-as-you-go costs. Considering these at design time dramatically reduces operational burden.

AZ-104 (Administrator) goes deep on VMSS in Domain 3 (Compute, 20-25%), making it the headline certification for this area. AZ-305 (Solutions Architect Expert) covers Auto Scale design from an architect perspective, AZ-204 (Developer Associate, retiring 2026-07) covers VMSS deployments from a developer angle, AZ-400 (DevOps Engineer Expert) covers automating VMSS Image updates from CI/CD pipelines, and AZ-140 (AVD Specialty) covers AVD host pools (internally VMSS). AKS node pools are built on internal VMSS. Understanding VMSS is an essential skill for any Azure compute engineer.