Azure VM Options: VMs, Scale Sets, Availability Sets, and Azure Virtual Desktop

Slide 1 / 13

Azure VM Options: VMs, Scale Sets, Availability Sets, and Azure Virtual Desktop

Introduction to Azure VM options: Virtual Machines, Virtual Machine Scale Sets, Availability Sets, and Azure Virtual Desktop.

4 VM-based options, 4 different goals

Choose based on the goal: control, scaling, availability, or desktops/apps. VM: one server you control. VMSS (Virtual Machine Scale Sets): scale a pool. Availability set: reduce correlated downtime. AVD (Azure Virtual Desktop): deliver desktops/apps to users.

Decision shortcut

Ask what you're delivering: a server, a scalable tier, resilience, or user desktops/apps. Need OS control → VM. Need scale-out/in pool → VMSS. Need FD/UD separation → availability set. Need user desktops/apps → AVD.

Azure Virtual Machines (VMs)

VMs give you OS control; you manage what's inside the machine. You choose and manage the guest OS. You control installed software and configuration. Azure runs the physical hardware. One VM equals one instance by default.

VMSS (Virtual Machine Scale Sets)

VMSS manages many similar VMs as a scalable pool. Group of VM instances managed as one unit. Scale out/in based on demand or schedule. Fits web/API tiers and worker pools. Goal: consistent, coordinated management.

Availability sets

Availability sets reduce correlated downtime inside one datacenter. Spread VMs across FD (Fault Domain) and UD (Update Domain). Reduces impact of hardware issues and maintenance. Helps availability, not scaling. Doesn't prevent OS/app failures inside the VM.

Scaling vs availability

VMSS scales capacity; availability sets reduce correlated downtime. Scaling equals add/remove instances to meet demand. Availability equals reduce downtime risk. VMSS → scaling a pool. Availability set → FD/UD separation.

AVD (Azure Virtual Desktop)

AVD delivers Windows desktops/apps to users, not general server compute. Desktop and app virtualization service. For end-user desktops and published apps. Often pooled or personal desktops. Uses VMs underneath, but managed as a delivery platform.

Scenario: one controllable server

Choose a VM when you need OS control and one instance is the design. Install software and configure OS. Workload not designed to scale out. Plan OS maintenance (patching, hardening). One VM doesn't equal HA (High Availability).

Scenario: demand spikes

Choose VMSS when you need a scalable pool of similar instances. Capacity grows/shrinks automatically. Instances are managed as one unit. Fit: web/API tier, worker pool. Goal: a stable pool, not 'pets' servers.

Scenario: redundancy inside a datacenter

Choose an availability set to reduce FD/UD correlated downtime for a few VMs. Small number of VMs (no autoscaling goal). Spread across FD/UD to reduce correlated downtime. Helps with maintenance and hardware events. App/OS failures still require your design.

Scenario: end-user desktops/apps

Choose AVD when the deliverable is desktops/apps for users. End users need Windows desktops or published apps. Centralized desktop/app delivery model. Often pooled capacity. Not the same as 'RDP (Remote Desktop Protocol) to a VM'.

Common pitfalls

Most mistakes come from confusing goals: control, scaling, availability, or desktops/apps. VM does not equal scaling/HA by default. VMSS equals scaling pool; availability set equals FD/UD separation. Availability set doesn't prevent OS/app failures. AVD isn't 'just RDP to a VM'.