Table of Contents
- What Are Azure Virtual Machine Scale Sets?
- Core Concepts You Must Know
- Orchestration Modes: Uniform vs. Flexible
- VMSS Architecture Overview
- Autoscaling Deep Dive
- Upgrade Policies Explained
- VMSS vs. Availability Sets vs. Availability Zones
- Integration with Azure Load Balancer
- Step-by-Step Tutorial: Deploy VMSS from the Portal
- Key Takeaways
- Frequently Asked Questions
What Are Azure Virtual Machine Scale Sets?
Azure Virtual Machine Scale Sets (VMSS) is a compute service that lets you deploy and manage a group of load-balanced, auto-scaling virtual machines. Rather than manually provisioning individual VMs and configuring each one, VMSS treats your entire fleet as a single managed resource — automatically adding or removing instances based on demand, health probes, or a schedule you define.
Think of it as Azure’s answer to the question: “What happens when one VM is no longer enough?” Whether you are running a web tier behind Application Gateway, a processing fleet for batch jobs, or a stateless microservice, VMSS gives you elastic capacity without the operational overhead of per-VM management.
AZ-104 Exam Relevance
VMSS is a testable topic under the Deploy and Manage Azure Compute Resources objective domain. Expect scenario questions on scaling policies, orchestration modes, and integration with Azure Load Balancer or Application Gateway.
Core Concepts You Must Know
Before deploying your first scale set, you need to understand the six pillars that define how VMSS works:
Instance Model
All VMs share the same OS image, size, and configuration. Changes to the model roll out via the upgrade policy.
Autoscale
Scales in/out based on CPU, memory, custom metrics, or a schedule. Rules are defined in Azure Monitor autoscale settings.
Upgrade Policy
Defines how model changes roll out: Manual, Automatic, or Rolling — each with different availability impact.
Health Monitoring
Application Health extension or Load Balancer probes report instance health. Unhealthy instances can be auto-repaired.
Fault Domains
Azure distributes instances across fault and update domains to maximise availability during hardware failures and maintenance.
Spot Instances
VMSS supports Azure Spot VMs for fault-tolerant workloads, cutting compute costs by up to 90% when capacity is available.
Orchestration Modes: Uniform vs. Flexible
This is one of the most important distinctions to understand — both for real-world deployments and the AZ-104 exam. Azure VMSS supports two orchestration modes, and choosing the wrong one can severely limit your options.
| Feature | Uniform Orchestration | Flexible Orchestration |
|---|---|---|
| VM Management | Managed by VMSS profile only | Full VM API access per instance |
| VM Size | Single SKU across all instances | Multiple VM SKUs supported |
| Max Instances | Up to 1,000 (platform image) | Up to 1,000 per region |
| Autoscale | ✓ Supported | ✓ Supported |
| Availability Zones | Supported | Supported (better zone balance) |
| Use Case | Stateless web tiers, identical VMs | Mixed workloads, phased migration |
| Recommended For | Classic workloads | ✓ New deployments |
Best Practice
Microsoft recommends Flexible orchestration for all new VMSS deployments. It gives you per-instance control while still supporting the full autoscale and load balancing feature set.
VMSS Architecture Overview
A production VMSS deployment involves several Azure services working together. Here is how the layers stack from top to bottom:
VMSS Reference Architecture
Autoscaling Deep Dive
Autoscale is the feature that makes VMSS genuinely powerful. Azure Monitor Autoscale evaluates your rules on a repeating cycle (typically every 1 minute) and scales in or out accordingly.
Scale-Out Rule — Adding Instances
A typical scale-out rule triggers when the average CPU across all instances exceeds 75% for 10 minutes. Azure then adds the configured number of instances and enters a cooldown period to prevent rapid oscillation.
Scale-In Rule — Removing Instances
The matching scale-in rule removes instances when the average CPU drops below 30% for 10 minutes. Always pair a scale-in with a scale-out rule — without it, your fleet only ever grows and your costs climb indefinitely.
Common Gotcha
The cooldown period (default 5 minutes) applies after every scale action. If your workload spikes unpredictably, consider lowering it — but too short a cooldown risks thrashing. A minimum of 3 minutes is recommended for most web tiers.
Instance Limits
- Minimum instances: The floor — VMSS never scales below this count, even at zero load.
- Maximum instances: The ceiling — caps spending and prevents runaway scale events.
- Default instance count: Used when metric data is unavailable, such as during initial deployment.
Upgrade Policies Explained
When you update the VMSS model — for example, changing the OS image version, adding an extension, or modifying the VM size — the upgrade policy controls how that change rolls out to existing instances.
| Policy | Behaviour | Availability Impact | Best For |
|---|---|---|---|
| Manual | Instances not updated until you explicitly trigger an upgrade per instance or for all. | No disruption | Dev/test, full control scenarios |
| Automatic | Azure immediately applies model changes to all instances, potentially restarting them simultaneously. | Possible downtime | Fast iteration, non-critical workloads |
| Rolling | Updates applied in batches with a configurable pause between batches. Requires health probes. | Zero downtime | Production stateless tiers |
VMSS vs. Availability Sets vs. Availability Zones
Understanding where VMSS fits relative to other high-availability constructs is a frequently tested AZ-104 concept:
- Availability Sets — Protect against rack-level hardware failures within a single datacenter. Support up to 3 fault domains and 20 update domains. No auto-scaling capability.
- Availability Zones — Protect against full datacenter failure by distributing VMs across physically separate zones within a region. Deliver the highest SLA at 99.99%.
- VMSS with Zones — Combines elastic auto-scaling with zone distribution. This is the recommended pattern for highly available, elastic production workloads on Azure.
AZ-104 Exam Tip
If an exam scenario asks how to build a web tier that handles traffic spikes and survives a datacenter outage, the answer is VMSS deployed across Availability Zones, combined with a Standard Load Balancer. Neither Availability Sets alone nor a single-zone VMSS satisfies both requirements simultaneously.
Integration with Azure Load Balancer
VMSS instances are automatically registered with an Azure Load Balancer backend pool when you configure one during deployment. Key points to know:
- Always use the Standard SKU load balancer. The Basic SKU does not support Availability Zones and has been retired for new deployments.
- Health probes (HTTP, HTTPS, or TCP) determine which instances receive traffic. Failing instances are removed from rotation — not deleted.
- When VMSS scales out, new instances are automatically registered with the backend pool. No manual NIC association is required.
- Inbound NAT rules in the load balancer can map unique external ports to RDP or SSH ports on individual scale set instances for direct management access.
Deploy a VMSS from the Azure Portal (Step-by-Step)
AZ104-Compute-RG) · Basic familiarity with the Azure Portal.Navigate to Virtual Machine Scale Sets
Sign in to the Azure Portal at portal.azure.com. In the top search bar, type Virtual Machine Scale Sets and select the service from the search results.
Click + Create to begin the deployment wizard.
Configure the Basics Tab
Fill in the required fields on the Basics tab:
- Subscription: Select your Azure subscription.
- Resource Group: Choose
AZ104-Compute-RGor your existing RG. - Virtual machine scale set name: e.g.,
vmss-webfront-001 - Region: e.g., East US or a region close to your users.
- Availability zone: Select Zones 1, 2, 3 for maximum resilience.
- Orchestration mode: Select Flexible — recommended for all new deployments.
- Security type: Trusted launch virtual machines is the default and recommended.
Choose Image and VM Size
Under Instance details on the Basics tab:
- Image: Click See all images and select Windows Server 2025 Datacenter: Azure Edition, or Ubuntu 22.04 LTS for Linux workloads.
- VM architecture: Leave as x64.
- Size: Click See all sizes and choose
Standard_D2s_v3(2 vCPUs, 8 GiB RAM) — a solid balanced choice for web workloads.
Lab Tip for vmorecloud.com: Use Standard_B2s to stay within minimal-cost boundaries. Never leave a running VMSS unmonitored — costs accumulate per instance.
Set Administrator Account
Scroll down to Administrator account:
- Authentication type: Choose SSH public key for Linux, or Password for Windows.
- Username: e.g.,
azureadmin - Password / SSH Key: Use a strong credential. Store it in Azure Key Vault for production environments.
Configure Scaling (Autoscale)
Navigate to the Scaling tab. This is where VMSS becomes powerful:
- Initial instance count: Set to
2— ensures two instances are running from day one for baseline availability. - Scaling policy: Select Custom (not Manual).
- Scale-out rule — CPU threshold:
75%| Duration:10 minutes| Add:1instance - Scale-in rule — CPU threshold:
25%| Duration:10 minutes| Remove:1instance - Minimum instances:
2 - Maximum instances:
10
Configure Networking and Load Balancer
Move to the Networking tab:
- Virtual network: Select or create a VNet (e.g.,
vnet-vmss-prod) and subnetsnet-web. - NIC network security group: Set to Advanced. Create or assign an NSG allowing HTTP (80), HTTPS (443), and RDP/SSH from your management IP only.
- Load balancing: Toggle on. Choose Azure Load Balancer.
- Load balancer name: Click Create new → name it
lb-vmss-webfront, type Public. - Backend pool:
bepool-webfront— Azure automatically maps new VMSS instances to this pool as they scale out.
Set the Upgrade Policy
Go to the Management tab and find Upgrade policy:
- Select Rolling for production deployments.
- Max batch instance percent:
20— updates 20% of instances per batch. - Max unhealthy instance percent:
20. - Optionally enable Automatic OS upgrades to let Azure auto-patch the OS image.
Review + Create
Click through to the Review + create tab. Azure runs a validation check — resolve any red-flagged fields before proceeding. Review the estimated cost at the bottom of the page, then click Create.
Deployment typically completes in 3–5 minutes. Navigate to your Resource Group → vmss-webfront-001 → Instances to confirm both initial instances show Provisioning state: Succeeded.
Verify Autoscale in Azure Monitor
Navigate to your VMSS resource and select Scaling from the left-hand menu to review your configured rules. To inspect scale history, go to Azure Monitor → Autoscale → vmss-webfront-001 → Run History. This shows every scale action with timestamps, before/after instance counts, and the metric value that triggered it.
Optional: Azure CLI — Manage Scale Set Instances
# List all instances in the scale set
az vmss list-instances \
--resource-group AZ104-Compute-RG \
--name vmss-webfront-001 \
--output table
# Manually scale to 4 instances
az vmss scale \
--resource-group AZ104-Compute-RG \
--name vmss-webfront-001 \
--new-capacity 4
Lab Reminder: After completing this lab, delete or deallocate your VMSS from Resource Group → vmss-webfront-001 → Delete to avoid unexpected charges on your vmorecloud.com lab subscription.
Key Takeaways
- VMSS is Azure’s managed fleet service — identical instances, one control plane, automatic load distribution.
- Flexible orchestration is the modern default — choose it for all new deployments unless you have a specific legacy reason to use Uniform.
- Autoscale requires paired rules — a scale-out rule without a matching scale-in rule means your fleet only ever grows, and so does your Azure bill.
- Rolling upgrade policy is production-safe — batch updates with health checks prevent full outages during model updates.
- Combine VMSS with Availability Zones for the highest SLA (99.99%) and zone-resilient auto-scaling.
- Standard Load Balancer is mandatory — the Basic SKU is retired for new deployments and does not support Availability Zones.
- For the AZ-104 exam — know the difference between Uniform and Flexible orchestration, the three upgrade policies, and when to use VMSS over Availability Sets.
Frequently Asked Questions
Can VMSS instances use different VM sizes?
Yes — but only with Flexible orchestration. Uniform orchestration requires all instances to share the same VM SKU. Flexible mode lets you specify different sizes per instance, which is useful for mixed workloads or gradual hardware migrations.
Does VMSS support stateful workloads?
VMSS is designed primarily for stateless workloads. For stateful applications, use Azure Service Fabric or persist state externally via Azure SQL Database, Cosmos DB, or Azure Files. For containerised stateful apps, consider the stateful node pool concept in AKS.
What happens to an instance during a scale-in event?
By default, Azure selects the instance with the highest instance ID for termination. You can customise this using the Scale-in policy setting — choosing OldestVM, NewestVM, or Default (highest ID). When the terminate notification feature is enabled, instances receive a graceful shutdown signal before deletion.
How is Azure VMSS priced?
You pay for the individual VM instances within the scale set — VMSS itself does not carry an additional service charge. Each instance is billed at the standard VM compute rate for its size and OS. Using Azure Spot instances within VMSS can reduce compute costs by up to 90% for fault-tolerant, interruptible workloads.
Can I use VMSS with Azure Kubernetes Service (AKS)?
Yes. AKS node pools are backed by VMSS. When you enable the Cluster Autoscaler in AKS, it scales the underlying VMSS node pools based on pod scheduling pressure. Understanding VMSS VM SKUs and Availability Zone coverage is therefore important when designing production AKS node pools.