Azure Virtual Machines: Scale Sets, Availability Sets, and Specialized Compute

An availability set protects a fixed group of virtual machines from a single datacenter’s hardware failures and maintenance reboots, while a Virtual Machine Scale Set automatically grows or shrinks a pool of identical, load-balanced VMs to match demand. They solve different problems — resilience versus elasticity — and a well-designed Azure deployment often uses scale sets configured with the resilience concepts availability sets pioneered, layered under Availability Zones for even stronger protection.

Virtual machines as infrastructure-as-a-service

An Azure virtual machine (VM) is an infrastructure-as-a-service (IaaS) resource: you get a guest operating system that you install, patch, and configure yourself, which is why VMs give you more administrative control over the OS than any platform-managed compute option. That control comes with responsibility — you decide the patch schedule, the installed software, and the security hardening.

Every VM deployment requires three things at minimum: a virtual machine size (SKU) that sets the available CPU and memory, a virtual network and subnet for the network interface to attach to, and an operating system image to install. The SKU choice should track the workload’s actual resource profile — a memory-intensive database needs a memory-optimized size, while a batch-processing job might prioritize CPU cores instead. Azure also automatically provisions an OS disk for every VM; it’s the one disk that’s always present and required, distinct from optional data disks you attach for application storage and the temporary disk used for short-lived files like page or swap data.

Availability sets: fault domains and update domains

An availability set exists for one purpose: reducing the chance that a single planned maintenance event or unplanned hardware failure takes down every VM in a related group at once, all within one Azure datacenter. It does this by spreading VMs across two independent groupings.

A fault domain is a group of VMs that share underlying hardware — a rack, a power source, a network switch — so a hardware failure in one fault domain doesn’t touch VMs in another. An update domain is a separate logical grouping Azure uses to stagger planned maintenance reboots, so the whole set never goes offline for patching simultaneously. Put two VMs running the same application in an availability set, and a single rack failure or maintenance window can knock out at most one fault or update domain’s worth of instances — not both.

What availability sets do not do matters just as much on the exam. They don’t autoscale instance count — that’s a scale set’s job. They don’t protect against the loss of an entire datacenter, because every VM in an availability set still lives inside one physical facility. And they have no relationship to backup, data recovery, or access control; they’re purely a placement strategy for fault and maintenance isolation.

Virtual Machine Scale Sets: elasticity, not just resilience

A Virtual Machine Scale Set deploys and manages a group of identical, load-balanced VMs whose instance count can automatically increase or decrease based on demand — typically paired with a load balancer that distributes incoming traffic across whatever instances currently exist. This is the answer whenever a scenario describes unpredictable or cyclical traffic: a retailer’s flash-sale spikes, a media site’s evening viewership surge, a trading platform whose load rises and falls with the market.

Scale sets inherit the fault-tolerance thinking of availability sets but add automation on top: instances can be distributed for resilience and the pool can resize itself without a human adjusting capacity. Configuring a scale set to span multiple Availability Zones extends that protection further, guarding against the loss of an entire datacenter within a region — something neither a single availability set nor a scale set confined to one zone can do, since both are still bounded by one facility’s fault domains. For the full mechanics of zone-level resilience, see Azure Availability Zones explained.

Specialized compute: Dedicated Host, Azure Batch, and Azure Virtual Desktop

Beyond general-purpose VMs, Azure offers a handful of purpose-built compute services that show up in AZ-900 scenario questions precisely because they solve narrow problems well.

Azure Dedicated Host provisions a physical server reserved entirely for one customer’s VMs — unlike the standard multi-tenant model, you control exactly which VMs land on that hardware and gain visibility into the underlying host. This is the answer whenever a scenario mentions a compliance or regulatory requirement that workloads run on hardware not shared with other tenants.

Azure Batch schedules and runs large-scale parallel and high-performance computing jobs across a managed pool of compute nodes, automatically scaling the pool up for the workload and tearing it down when the job finishes. Look for language about splitting a simulation or rendering job into thousands of parallel tasks with no need for an interactive session — that’s Batch, not a scale set or Azure Virtual Desktop.

Azure Virtual Desktop delivers a full Windows desktop and application experience remotely, including multi-session Windows that lets several users share one Windows instance simultaneously. It supports two host pool models worth distinguishing: a pooled host pool load-balances users across a shared set of session hosts, while a personal host pool gives each user a dedicated, one-to-one assigned machine so their settings and files persist between logins — the fit for a call center where every agent returns to the same desktop each shift.

For workloads that tolerate interruption, Azure Spot Virtual Machines offer unused Azure capacity at a steep discount in exchange for the risk that Azure reclaims the capacity with little notice — a good match for interruptible batch rendering or overnight jobs that can simply restart. That’s a different lever from resilience or scaling; it’s purely a cost-versus-availability trade-off, covered in more depth alongside Azure’s other purchasing options.

Availability set vs. scale set vs. Availability Zones

Feature	Availability Set	VM Scale Set	Availability Zones
Primary goal	Fault/maintenance isolation for a fixed group of VMs	Autoscaling a pool of identical, load-balanced VMs	Protection from loss of an entire datacenter
Scope	Single datacenter	Single datacenter (unless zone-enabled)	Multiple physically separate datacenters in a region
Autoscales instance count	No	Yes	N/A (a placement option, not a scaling feature)
Mechanism	Fault domains + update domains	Load balancer + autoscale rules	Independent power, cooling, and network per zone

How the AZ-900 exam tests this

• A scenario describes VMs that need to survive planned maintenance or a rack-level hardware failure but explicitly says autoscaling isn’t needed — the answer is an availability set, not a scale set.
• A scenario describes unpredictable or cyclical traffic and identical, load-balanced instances that must grow and shrink automatically — the answer is a Virtual Machine Scale Set, and if it also mentions surviving the loss of an entire datacenter, the correct answer adds Availability Zones on top.
• A scenario mentions regulatory or compliance language about hardware not being shared with other tenants — that’s Azure Dedicated Host, not a scale set or availability set.
• A scenario describes remote workers needing a full Windows desktop and their applications without shipping physical machines — that’s Azure Virtual Desktop; if it adds “the same desktop every day with personal settings,” it’s specifically a personal host pool.

Quick reference

• Availability sets isolate VMs within one datacenter using fault domains (hardware) and update domains (maintenance) — no autoscaling.
• VM Scale Sets autoscale identical, load-balanced VM instances based on demand; add Availability Zones to survive a datacenter-level outage.
• Every VM deployment needs a size (SKU), a network/subnet, and an OS image; every VM gets an OS disk automatically.
• Azure Dedicated Host = single-tenant physical hardware; Azure Batch = large-scale parallel job scheduling with automatic teardown.
• Azure Virtual Desktop delivers remote Windows desktops — pooled host pools share session hosts, personal host pools assign one machine per user.
• Spot VMs trade eviction risk for steep discounts on interruptible workloads.

Ready to test what you’ve learned? Practice these concepts with real AZ-900 exam questions that mirror how Microsoft phrases scale set, availability set, and specialized compute scenarios.