2.3 Azure Virtual Machines
Key Takeaways
- Azure Virtual Machines (VMs) are Infrastructure as a Service (IaaS): you control the operating system, runtime, and apps while Microsoft runs the physical hardware, network, and datacenter.
- VM families map to workload shapes — General Purpose (B/D), Compute Optimized (F), Memory Optimized (E/M), Storage Optimized (L), GPU (N), and High Performance (H); know the purpose, not the sizes.
- Virtual Machine Scale Sets (VMSS) create and autoscale up to 1,000 identical, load-balanced VMs, using Flexible (recommended) or Uniform orchestration.
- Availability Sets protect against rack-level hardware faults and host patching INSIDE one datacenter using fault domains and update domains; Availability Zones protect against a whole datacenter failing.
- Spot VMs use spare capacity at up to ~90% off but can be evicted with 30 seconds' notice; Dedicated Hosts give you a single-tenant physical server for compliance and Bring-Your-Own-License.
Quick Answer: Azure Virtual Machines are IaaS compute. You pick an OS image, a size, disks, and a virtual network, then manage everything from the OS up. Microsoft manages the hypervisor, hardware, and datacenter. VMs bill per second while running and come in families tuned for different CPU-to-memory ratios.
What an Azure VM Actually Is
An Azure Virtual Machine (VM) is an on-demand, software-defined computer that runs on Microsoft's hardware. Creating one provisions several linked resources at once: the VM object itself, an OS disk (and optional data disks) in Azure Managed Disks, a network interface card (NIC), a public IP (optional), and membership in a virtual network (VNet). Deleting a VM does not automatically delete those disks or IPs, which is a classic source of surprise charges.
VMs sit at the IaaS layer of the shared responsibility model. You own OS patching, antivirus, the runtime, the application, and network configuration. Microsoft owns the physical host, the hypervisor, power, cooling, and the physical network. On the exam, "the customer needs full control of the operating system" is the phrase that points to VMs over App Service or Functions.
VM Families and Series
Azure groups VM sizes into families by the ratio of CPU, memory, storage throughput, and accelerators. Memorize the purpose, never the size codes or prices.
| Family | Example series | Optimized for | Typical workloads |
|---|---|---|---|
| General Purpose | B, D, Dv5 | Balanced CPU-to-memory | Web servers, dev/test, small-to-medium databases |
| Compute Optimized | F, Fx | High CPU per GB of RAM | Batch processing, game servers, web tier under heavy CPU |
| Memory Optimized | E, Ev5, M | High RAM per vCPU | Large relational databases, in-memory caches, SAP HANA |
| Storage Optimized | L | High local disk IOPS and throughput | Big data, NoSQL (Cassandra), data warehousing |
| GPU | N, NC, ND, NV | Graphics and parallel compute | ML training/inference, rendering, video encoding |
| High Performance | H, HB, HC | Fastest CPUs, optional RDMA networking | Fluid dynamics, molecular modeling, weather sims |
On the Exam: The B-series is "burstable" — it banks CPU credits when idle and spends them during spikes, making it the cheapest pick for low-average-load dev/test servers. Match the bottleneck resource in the scenario (RAM-bound → Memory Optimized; CPU-bound → Compute Optimized).
Scale Sets and Orchestration Modes
Azure Virtual Machine Scale Sets (VMSS) deploy and manage a group of identical, load-balanced VMs that grow and shrink automatically. A single scale set supports up to 1,000 VM instances. Autoscale rules react to metrics such as average CPU percentage, or to a fixed time schedule (for example, scale to 10 instances at 8 a.m.).
VMSS offers two orchestration modes:
- Flexible (Microsoft's recommended default for new workloads) — can mix VM sizes and combine Spot with regular instances, and spreads VMs across fault domains automatically.
- Uniform — every instance is identical from one VM profile; best for large stateless front ends.
Use Scale Sets for variable-traffic web tiers, queue-driven batch workers, and any "add more identical servers under load" pattern.
Availability Sets vs Availability Zones
This distinction is one of the most heavily tested ideas in Domain 2. An Availability Set is a logical grouping that spreads VMs across hardware boundaries inside a single datacenter, raising the Service Level Agreement (SLA) for those VMs.
| Concept | What it is | Limit |
|---|---|---|
| Fault Domain (FD) | VMs sharing one power source and network switch (a rack). Azure spreads your VMs across FDs so a rack/power failure cannot take all of them down. | Up to 3 |
| Update Domain (UD) | A group rebooted together during planned host maintenance, so patching never reboots every VM at once. | Up to 20 |
An Availability Zone is a physically separate datacenter (its own power, cooling, and network) within an Azure region; each enabled region has at least three. Placing VMs in different zones protects against an entire datacenter failing — a far larger blast radius than an Availability Set covers.
On the Exam: Availability Set = protection from rack failure and host patching within one datacenter. Availability Zone = protection from a whole datacenter going down. Single-VM SLA requires Premium SSD/Ultra disks; two or more VMs in an Availability Set or across Zones reach the higher VM availability SLA.
Dedicated Hosts and Spot VMs
Azure Dedicated Host gives your organization an entire physical server that no other tenant shares. You pay for the host whether or not VMs run on it. It exists for three reasons: regulatory compliance that forbids shared hardware, Bring-Your-Own-License (BYOL) for Windows Server or SQL Server, and control over the host's maintenance window.
Azure Spot VMs rent unused capacity at deep discounts — commonly up to ~90% below pay-as-you-go. The catch: Azure can evict a Spot VM whenever it needs the capacity back or the price exceeds your cap, giving only about 30 seconds of notice. That makes Spot ideal for interruptible work — CI/CD build agents, rendering, large batch jobs, dev/test — and unsuitable for stateful production databases.
When to Use VMs vs Other Compute
| Scenario | Best service | Why |
|---|---|---|
| Need full OS control or a legacy lift-and-shift | Azure VMs | IaaS — you own the OS |
| Host a web app with no OS management | Azure App Service | PaaS handles patching and scaling |
| Short event-driven code, pay per run | Azure Functions | Serverless, scale to zero |
| Orchestrate many containers | Azure Kubernetes Service | Managed Kubernetes |
| Virtual desktops for end users | Azure Virtual Desktop | Managed VDI |
Common Traps
- Deleting a VM leaves its managed disks and public IP behind — they keep billing.
- An Availability Set does not survive a datacenter outage; only Zones do.
- A stopped (not deallocated) VM in the portal still incurs compute charges; you must Stop (deallocated) to stop paying for compute (disks still bill).
An in-memory analytics database needs far more RAM than CPU. Which VM family is the best fit?
A team must guarantee that a planned host patch never reboots all of their VMs at the same time inside one datacenter. Which feature addresses this?
Which statement about Azure Spot VMs is correct?