Academmia

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

az-900•mixed•

Azure architecture and services

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

Short Summary

In this lesson, you’ll compare the main “VM-based” choices in Azure and the specific problem each one solves. You’ll see the difference between a single Azure Virtual Machine (VM), Azure Virtual Machine Scale Sets (VMSS), and availability sets. You’ll also learn when Azure Virtual Desktop (AVD) is the right fit because the goal is end-user desktops and apps, not general server compute.

Learning Objectives

By the end of this lesson, you will be able to:

  • Define what a VM, VMSS, availability set, and AVD provide at a high level.
  • Differentiate these options by their primary goal: control, scaling, availability, or desktop/app delivery.
  • Explain how fault domains (FDs) and update domains (UDs) improve availability in an availability set.
  • Choose the most appropriate VM-based option for common workload scenarios.
  • Spot common misconceptions that lead to picking the wrong option.

Core Concepts

Azure Virtual Machines (VMs): the baseline “server I control”

Azure Virtual Machines (VMs) are on-demand computing resources where I choose and manage the guest operating system (OS) and what runs on it. The big reason to pick a VM is control: I can configure the OS and installed software like I would on a traditional server (while Azure runs the underlying physical hardware).

Azure Virtual Machine Scale Sets (VMSS): scaling a pool of similar VMs

Azure Virtual Machine Scale Sets (VMSS) let me create and manage a group of load-balanced VM instances as one unit. The instance count can increase or decrease based on demand or a schedule, which makes VMSS a strong fit for web front ends, API tiers, or worker pools where “more traffic = more instances.”

Availability sets: availability within a datacenter, not scaling

An availability set is about reducing correlated downtime for a small set of VMs by spreading them across different fault domains (FDs) and update domains (UDs) within an Azure datacenter. The platform assigns each VM in the set an FD and UD so that a single hardware issue or planned maintenance event is less likely to affect all your VMs at once. This improves resilience, but it doesn’t automatically add/remove instances to match demand.

Important nuance: availability sets help with physical infrastructure and maintenance blast radius, but they don’t protect you from OS or application failures inside the VM.

Azure Virtual Desktop (AVD): desktops and apps for end users

Azure Virtual Desktop (AVD) is a desktop and app virtualization service that delivers Windows desktops and/or published applications to end users. I use it when the product I’m delivering is “people need a desktop/app experience” (often pooled or personal desktops), not “I need another server.” Under the hood, AVD uses VMs, but I consume it as a desktop/app delivery platform with its own concepts and management model.

Practical Understanding

Practical Situation 1: When you need one controllable server, think “single VM”

You need a Windows or Linux server where you install software, configure the OS, and run a workload that isn’t meant to scale out horizontally. The focus is control over the machine, not autoscaling or end-user desktops.

How to think about it: Use a VM as your base building block. Plan for OS maintenance (updates, configuration, security hardening) as part of the workload.

Common misunderstanding: Assuming “VM” automatically means high availability or scaling. A single VM is one instance unless you design for resilience and scale around it.

Practical Situation 2: When traffic goes up and down, think “VMSS”

Your app has spikes (predictable or not) and you want capacity to grow and shrink without manually creating and deleting VMs. You want many similar instances managed as a pool.

How to think about it: Use VMSS so you can manage the group consistently and scale the instance count based on demand or schedules.

Common misunderstanding: Thinking VMSS is “just a bunch of random VMs.” The point is consistent configuration and coordinated management so the tier behaves like a pool.

Practical Situation 3: When you need redundancy inside one datacenter, think “availability set”

You run a workload on a small number of VMs (for example, two or three instances) and autoscaling is not the goal, but you still want to reduce the chance that planned maintenance or a single hardware failure takes all instances down together.

How to think about it: Use an availability set to distribute VMs across FDs and UDs. This reduces the “everything went down together” risk for infrastructure and maintenance events.

Common misunderstanding: Confusing availability sets with scaling. Availability sets are about reducing correlated failures, not adding/removing instances to match demand.

Practical Situation 4: When the requirement is “users need desktops/apps,” think “AVD”

A company wants people to connect to Windows desktops or published apps from many locations and devices. They want centralized delivery and often want pooled capacity rather than one VM per person.

How to think about it: Use AVD because it’s designed for desktop/app delivery to users. It’s not a generic “run any server workload” service; it’s purpose-built for end-user computing scenarios.

Common misunderstanding: Treating AVD as “a normal VM you remote into.” AVD uses VMs underneath, but the service is optimized around delivering desktops/apps and managing that experience.

Common Pitfalls

  • Mistake: Treating all VM-based options as interchangeable. Correction: Match the option to the goal: VM for OS control, VMSS for scaling a pool, availability set for datacenter-level resilience, and AVD for end-user desktops/apps.

  • Mistake: Mixing up availability sets and VMSS. Correction: Use availability sets to reduce FD/UD blast radius for a few VMs; use VMSS when you want to scale out/in a pool of similar instances.

  • Mistake: Assuming availability sets eliminate application downtime. Correction: Availability sets reduce infrastructure/maintenance correlation, but OS/app reliability is still on you (design, monitoring, patching, and app health).

  • Mistake: Thinking AVD is “just RDP to a VM.” Correction: Choose AVD when you need desktop/app virtualization for users; choose VMs/VMSS when you need server compute for applications and services.

  • Mistake: Expecting scaling or redundancy to happen “by default.” Correction: Scaling requires VMSS configuration; redundancy requires deliberate placement (availability set and/or other availability options) and multiple instances.

Check Your Understanding

  1. Describe a real workload that should run on a single VM. What makes it a poor fit for scaling out?
  2. For a web app with busy hours and quiet hours, explain how VMSS changes your operational approach compared to managing separate VMs by hand.
  3. In your own words, explain the difference between “scaling” and “availability” using VMSS and availability sets as examples.
  4. Write a short rule-of-thumb you could use to decide between “a VM” and “AVD” when someone says, “I need remote access.”
  5. List two clarifying questions you would ask a stakeholder to avoid choosing AVD when they actually need server compute (or choosing VMs when they actually need user desktops/apps).

Further Reading