Azure Virtual Machines Explained

The resources created with a VM, how to read VM size names, availability set and availability zone SLAs with fault and update domains, and how scale sets and Azure Virtual Desktop differ, in the order the AZ-900 outline asks about them.

Azure Virtual Machines (VMs) are the first compute service you learn for AZ-900, but the skills outline revised in July 2026 asks more about what surrounds a VM than about the VM itself. "Resources required for virtual machines" and "availability sets" are listed as separate items, and scale sets and Azure Virtual Desktop are meant to be compared within the same objective.

This post is the VM supplement to our AZ-900 deep-dive series. If Compute and Networking gave you a broad tour of the compute services, this one goes through a single VM in the order the exam asks about it, from the resources created alongside it to the ways you place VMs to survive failures.

---

 

When Do You Use a VM?

A VM is IaaS (infrastructure as a service). You don't have to buy or maintain physical servers, but patching, updating, and configuring the operating system inside the VM is still your responsibility. In rental-car terms, you rent the car, but you still do the driving and refueling. Because you get that much control, you pick a VM when you need to work with the operating system directly.

| Use case | Description | |------|------| | Testing and development | Quickly create different OS and app configurations, then remove them when testing is done | | Hosting apps in the cloud | Run apps and scale capacity up or down as demand changes | | Extending the datacenter | Extend an on-premises network into Azure and run workloads in a connected virtual network | | Disaster recovery | Run critical workloads in Azure when the primary site is unavailable | | Lift-and-shift migration | Move existing servers as they are, with little or no application redesign |

Exam tip: Phrases like "needs full control of the operating system," "move existing servers without modification," or "must install specific software directly" point to VMs. By contrast, "deploy only a web app without managing infrastructure" points to a PaaS service such as App Service.

---

 

Resources You Choose When Creating a VM

This is the "resources required for virtual machines" objective. Just as renting a car means choosing the model, the trunk size, and even the roads you will drive on, creating a VM does not create one thing. Several resources are created or connected along with it.

| Resource | Role | What you decide | |------|------|------| | VM size | The VM's performance | Purpose, number of vCPUs, amount of memory (RAM) | | OS disk | The disk where the operating system is installed | HDD or SSD type and capacity | | Data disks | Separate disks for application data (optional) | Number, type, capacity | | Network interface (NIC) | The card that connects the VM to a virtual network | The subnet to join, the private IP | | Virtual network and subnet | The network the VM lives in | Address space and subnets | | Public IP address | The address for reaching the VM from the internet (optional) | Whether to assign one | | Network security group (NSG) | Rules that decide which ports are open | Whether to allow ports like RDP (3389), SSH (22), and HTTP |

Because these resources exist separately from the VM, depending on how you delete the VM and how it is configured, disks or a public IP can stay behind and keep generating charges. After hands-on practice, getting into the habit of deleting the entire resource group keeps you safe.

Exam tip: When you "stop (deallocate)" a VM, compute charges stop, but disk storage charges continue. Also remember that if you only shut down from inside the operating system without deallocating, compute charges keep running too.

How to Read a VM Size Name

A VM size name carries information about its purpose and performance. For example, D2s_v5 reads like this.

| Part of the name | Meaning | |------|------| | D | VM family (general purpose) | | 2 | Two vCPUs | | s | Supports Premium SSD | | v5 | Hardware generation for that family |

The family letter tells you what kind of workload the VM suits. For AZ-900, rather than memorizing letters, it is enough to understand the flow: pick the family that matches the workload first, choose the size that meets the performance you need, then adjust as demand changes.

| Family | Characteristic | Typical use | |------|------|------| | B | Burstable, low cost | Dev and test with occasional CPU spikes | | D | General purpose | Web servers, small to medium app servers | | E | Memory optimized | In-memory databases, analytics | | F | Compute optimized | CPU-intensive application tiers | | M | Large memory | Large enterprise databases | | L | Storage optimized | High-throughput storage and data processing | | N | GPU enabled | AI training and inference, graphics |

---

 

VM Availability Options: From a Single VM to Availability Zones

A single VM stops when the hardware it sits on has a problem. That is why you run several VMs and choose how to place them based on how large a failure you need to survive. The wider the placement, the bigger the failure it can withstand and the higher the SLA.

| Configuration | Failure it protects against | VM connectivity SLA | |------|------|------| | Single VM (all disks Premium SSD or Ultra Disk) | No failure-tolerant placement | 99.9% | | Availability set (two or more VMs) | Rack-level hardware failure, planned maintenance reboots | 99.95% | | Availability zones (two or more VMs across two or more zones) | Failure of an entire datacenter | 99.99% | | Replication to another region (using region pairs) | A disaster that affects a whole region | A matter of disaster recovery design, not the VM SLA |

!Comparing VM availability options

Fault Domains vs Update Domains

An availability set spreads VMs using two kinds of grouping. Picture an apartment complex: a fault domain is the set of buildings that share one electrical panel, and an update domain is the set of buildings inspected on the same day.

| Category | Fault domain | Update domain | |------|------|------| | How VMs are grouped | VMs that share a power source and network switch | VMs that can be rebooted together during planned maintenance | | What it prepares for | Hardware failures such as power loss or a switch fault | Planned maintenance of the Azure platform | | Maximum number | 3 | 20 |

Maintenance proceeds one update domain at a time, and a rebooted domain gets 30 minutes to recover before maintenance moves to the next one. If an availability set has five update domains and six VMs, the sixth VM goes into the same update domain as the first. The availability set itself costs nothing extra; you pay only for the VMs.

Availability Sets vs Availability Zones

| Category | Availability set | Availability zones | |------|------|------| | Where the VMs are placed | Different racks inside one datacenter | Physically separate datacenters within one region | | Failure it withstands | Rack-level failures (not the loss of a whole datacenter) | Failure of an entire datacenter | | Latency between VMs | Lower (physically close together) | Relatively higher because traffic crosses zones | | Typical use | Regions that don't support availability zones | The default choice in regions that support availability zones |

Exam tip: If you see "highest availability" or "even if one datacenter goes down," the answer is availability zones. Microsoft recommends zone-based designs first in regions that support availability zones, and recommends Virtual Machine Scale Sets in Flexible orchestration mode for new configurations that need high availability.

---

 

Virtual Machine Scale Sets: Growing and Shrinking Identical VMs Automatically

Scale sets let you manage a group of identically configured VMs as one unit. It is like an amusement park opening more ticket windows when crowds arrive and closing them when things quiet down. Without scale sets, you would have to keep each VM's configuration consistent, watch utilization, and adjust the number of VMs yourself.

| Feature | Details | |------|------| | Identical configuration | VMs are created from the same image and settings, as if stamped out | | Autoscale | Automatically adds or removes VMs based on demand (such as CPU usage) or a schedule | | Load balancing integration | Works with Azure Load Balancer to spread traffic evenly | | Scale | Up to 1,000 VMs with marketplace images | | Pricing | The scale set itself is free; you pay only for the VMs, networking, and storage used |

| Category | Availability set | Virtual Machine Scale Sets | |------|------|------| | Main purpose | Spread VMs out to survive failures | Adjust the number of VMs automatically to match demand | | VM configuration | Each VM is created separately | Created in bulk from the same image | | Autoscale | No | Yes |

Exam tip: "Automatically add VMs as traffic grows" and "manage hundreds of identical VMs at once" point to scale sets. They also appear often as a concrete example of scalability and elasticity.

---

 

How Is Azure Virtual Desktop Different?

Azure Virtual Desktop (AVD) also runs on VMs under the hood, but its purpose is different. A VM gives you a server to rent; AVD delivers Windows desktops and apps from the cloud that users can reach from anywhere.

| Category | Azure Virtual Machines | Azure Virtual Desktop | |------|------|------| | What it provides | Server compute resources | Windows desktops and apps for users | | Main users | Administrators and developers who run applications | Employees working remotely | | Characteristic | Configure anything from the operating system up | Supports Windows 11 and 10 Enterprise multi-session, where several users share one VM | | Clue in the question | "Move servers to the cloud" | "Give remote workers the company desktop environment" |

---

 

Practice with Scenarios

Read each situation, think of the answer first, then check the columns on the right.

| Situation | Answer | Why | |------|------|------| | Special software must be installed directly on the operating system | Azure Virtual Machines | IaaS gives co

Back to blog list