Virtual Machines
A Virtual Machine is a computer you rent by the second: you pick the hardware shape, pick an operating system image, attach disks and a network card, and Azure boots it on a hypervisor in one of its datacentres. Everything above the hypervisor — patching, hardening, the application, the uptime — is yours.
Names: the service is Azure Virtual Machines, and its scale-out sibling is Virtual Machine Scale Sets (VMSS) — the newer, recommended form of which is the Flexible orchestration mode, with the original now called Uniform. You will still see the old "availability set" and "classic (ASM) VM" vocabulary in older documentation; classic VMs are retired, and this topic uses the Resource Manager model throughout.
What it is and where it fits
Virtual Machines are the bottom of the Azure compute stack and the reason most of the rest of the catalogue exists. A VM gives you an operating system with root or Administrator access, which is simultaneously the most powerful and most expensive thing Azure sells you — powerful because anything that runs on Linux or Windows runs here unchanged, expensive because you now own kernel patching, image hygiene, drift, backup, and the 3 a.m. page.
The problem it solved is the one that created the cloud: buying a physical server meant a purchase order, a rack, a three-year depreciation schedule, and a capacity guess made a year before the traffic arrived. A VM turns that capital decision into an API call you can undo in a minute. That's it — the rest of the service is detail around that one idea.
Azure's compute catalogue overlaps itself heavily, and choosing wrongly here is the most common architectural mistake on the platform. The neighbours, separated in a line each:
- App Service — you bring code, Azure brings the OS and the web server. Choose it for a straightforward web app or API; you lose OS access and the ability to run arbitrary daemons.
- Azure Container Apps — you bring a container, Azure brings the Kubernetes-shaped runtime without the cluster. Choose it for microservices and event-driven containers; you lose node-level control and some networking primitives.
- Azure Kubernetes Service (AKS) — you bring containers and want the full Kubernetes API. Note that AKS nodes are themselves VM Scale Sets, so understanding VMs is a prerequisite, not an alternative.
- Azure Functions — you bring a function, Azure brings everything else and scales it to zero. Choose it for bursty, short, event-triggered work.
- VM Scale Sets — the same VM, multiplied and managed as a set, with autoscale and rolling upgrades. If you find yourself deploying "three identical VMs", you wanted a scale set.
The honest rule: a VM is the right answer when something about the workload rules the others out — a licensed commercial application, a GPU driver, a specific kernel module, a lift-and-shift migration, a legacy Windows service, or a compliance requirement to control the host image. It is the wrong answer when it's simply the most familiar option.
If you're coming from AWS: an Azure VM is an EC2 instance, and the mental model transfers almost completely — instance family ≈ VM series, AMI ≈ image, EBS ≈ managed disk, security group ≈ NSG. Where it breaks: Azure's NIC is its own ARM resource that you can see and manage separately, the OS disk is always a separate resource with its own lifecycle, availability zones are opt-in per VM rather than derived from the subnet, and Azure has no direct equivalent to an instance profile — you use a managed identity instead.
Key facts at a glance
| Category | Compute — Infrastructure as a Service |
| Resource provider | Microsoft.Compute/virtualMachines (and Microsoft.Compute/virtualMachineScaleSets) |
| Companion providers | Microsoft.Network/networkInterfaces, Microsoft.Compute/disks, Microsoft.Network/networkSecurityGroups |
| Scope | Regional, and optionally zonal — a VM is pinned to one availability zone if you ask for one, and to none if you don't |
| The SKU axis | The VM size (series + generation + size), e.g. Standard_D4s_v5. Series letter = purpose (D general, E memory, F compute, B burstable, L storage, N GPU, M huge memory), s = premium-storage capable, the version number = hardware generation |
| Second SKU axis | The disk SKU — Standard HDD, Standard SSD, Premium SSD, Premium SSD v2, Ultra Disk. This drives as much of the performance and the bill as the VM size does |
| Unit of billing | Per second of allocated compute time, plus disks (provisioned size, billed whether the VM runs or not), plus egress, plus public IP, plus any OS licence |
| The billing trap | Stopping a VM from inside the guest OS keeps billing it. Only deallocating it (portal "Stop", or az vm deallocate) releases the compute charge — and disks keep billing regardless |
| SLA posture | Tiered by resilience choice: highest for a VM spread across availability zones, lower for an availability set, lower still for a single VM, and that single-VM SLA requires premium or ultra disks ⚠️ verify current percentages against current Azure docs |
| Usual companions | Virtual Network + NSG, Managed Disks, Key Vault, Azure Monitor + Azure Monitor Agent, Azure Backup, Azure Bastion, Managed Identity |
| Primary alternative | App Service or Container Apps for web workloads; AKS for containers; Functions for event-driven code |
| AWS rough analogue | EC2 (+ Auto Scaling Groups ≈ VM Scale Sets) |
When to use a VM
- Lift-and-shift migrations. The application predates containers, has an installer, and nobody wants to touch it. A VM is the only landing zone that requires zero application change.
- Licensed commercial software that is certified against a specific OS build — SAP, Oracle, many ISV appliances, most virtual network appliances.
- Anything needing kernel or driver control — GPU workloads with a specific CUDA driver, custom kernel modules, eBPF tooling, specialised filesystems.
- Long-running, predictable, high-utilisation compute, where a reservation or savings plan makes VMs meaningfully cheaper than a per-request platform.
- Workloads with hard host-level compliance requirements — where you must own the image, the patch baseline, and the audit trail, or need a dedicated host with no tenant neighbours.
- Self-hosted infrastructure — build agents, jump boxes, self-hosted integration runtimes, domain controllers.
When not to use a VM
- A plain web app or REST API. App Service or Container Apps will cost less and page you less.
- Bursty, short-lived, or scale-to-zero work. A VM bills while idle; Functions and Container Apps don't.
- "We need three identical servers behind a load balancer." That's a Virtual Machine Scale Set, and building it by hand from individual VMs gives up autoscale, rolling upgrades, and automatic instance repair.
- A container workload where you also plan to install Docker on the VM by hand. You are rebuilding Container Apps or AKS badly, and you now own the node lifecycle.
- Anything where nobody has agreed to own patching. An unpatched, internet-exposed VM is the single most common way an Azure subscription gets compromised. If there is no patching owner, choose a PaaS service instead — this is a genuine architectural criterion, not a lecture.
What this topic covers
| Sub-topic | What it covers |
|---|---|
| What & Why | The problem VMs solve, the compute-catalogue decision, the AWS analogue and where it breaks, and the honest anti-patterns |
| Core Concepts | VM sizes and series, images and generations, managed disks, NICs and IPs, NSGs, availability sets vs. zones, scale sets, extensions, and the SKU traps |
| Architecture | What actually happens during a boot, control plane vs. data plane, the disk I/O path and caching, allocation failures, throttling, scaling, and the failure modes |
| Getting Started | One Linux VM, three ways — portal, az CLI, and a minimal Terraform snippet — plus teardown |
| Deployment | A parameterised Terraform module, remote state, an Ansible playbook for in-guest config, the Bicep equivalent, OIDC-based CI/CD, environments, rollback, and drift |
| Integrations | Key Vault, Azure Monitor, Load Balancer and Application Gateway, Azure Backup, Bastion, Entra ID login, and the two glue mechanisms that recur everywhere |
| Production | Security, cost, scaling and quota scopes, observability, and reliability — the five pillars that separate a demo from a running system |
| Interview Questions | Three tiers of questions with answer keys, from "what is a VM" to "someone resized this by hand, now what" |
| Glossary & Cheatsheet | Every term in one line each, the commands you'll actually type, the resource ID shape, and the limits worth memorising |
Two ideas worth carrying into every other page
Deallocate is not stop, and stop is not delete. A VM has three power states that people conflate.
Shutting down from inside the guest leaves the VM allocated — Azure is still holding CPU and RAM for
you and still billing you. az vm deallocate releases the hardware and stops the compute charge, but
keeps the disks, the NIC, and the configuration, and may move the VM to different physical hardware on
the next start (which is why a dynamic public IP changes and why an allocation failure can happen on
start, not just on create). az vm delete removes the VM resource — and by default may leave the disks
and NIC behind as orphaned, still-billing resources.
The VM is not one resource; it's the centre of a small constellation. A single "VM" in the portal
is a virtualMachines resource plus at least one disks resource, a networkInterfaces resource, a
publicIPAddresses resource, and usually a networkSecurityGroups resource — each with its own ARM
resource ID, its own lifecycle, and its own line on the bill. Almost everything that surprises people
about Azure VMs — orphaned disks, an NSG that survives a rebuild, a public IP that can't be released —
follows from this one fact. AWS hides most of this; Azure makes you look at it.
Reading paths
New to Azure VMs — What & Why → Core Concepts → Getting Started. Build one, delete it, then come back for Architecture.
Coming from EC2 — skim What & Why, then go straight to Core Concepts for the size/disk/NIC model, and Architecture for the control-plane / data-plane split, which has no clean EC2 equivalent.
Need to ship this week — Deployment first, then Production. Getting Started is deliberately throwaway; don't build on it.
Interview or certification prep — Core Concepts, Architecture, and Interview Questions. The zones-vs-sets question and the deallocate-vs-stop billing question come up constantly.
Chasing a cost surprise — the cost section of Production, then the power-state discussion in Architecture. Orphaned disks and always-allocated dev VMs are the usual culprits.
Next: What & Why →