Understanding Azure Virtual Machines

You’ve probably already clicked through the Azure portal and launched a VM once. It booted, you connected, and it worked. But then you looked at the size dropdown and saw names like Standard_D4ads_v5 and Standard_E16bds_v5, a disk menu with five options, and a setting called “availability options” that seemed to matter a lot. This article fills in the why behind those choices, so the next VM you build is one you chose on purpose, not one you got by accepting the defaults.

We already covered the click-by-click walkthrough in Creating Your First Azure Virtual Machine, and we explored the AWS and Google equivalents in Deep Dive into AWS EC2 Instances and Exploring GCP Compute Engine Instances. Here we zoom in on the Azure building blocks themselves.

What an Azure VM actually is

An Azure Virtual Machine is a slice of a physical server in a Microsoft datacenter. The Azure hypervisor carves that server up and hands your VM a fixed number of virtual CPUs (vCPUs), a fixed amount of memory, and a connection to the network and storage. It is Infrastructure as a Service (IaaS): Microsoft looks after the building, the hardware and the hypervisor, and you look after the operating system and everything inside it. (Need a refresher on that split? See Cloud Service Models: IaaS, PaaS, SaaS.)

A handy analogy: renting a VM is like renting a furnished apartment. The landlord (Azure) owns the building and fixes the plumbing. You choose the apartment size, bring your own furniture (software), and lock the door (security patches and firewall rules are on you).

A VM is never alone

One thing that surprises newcomers is that a “VM” in Azure is really a small bundle of separate resources, all living in a resource group:

flowchart TB
    RG["Resource group"] --> VM["Virtual machine (size, image)"]
    VM --> OS["OS disk (managed disk)"]
    VM --> DD["Data disks (optional)"]
    VM --> NIC["Network interface (NIC)"]
    NIC --> SUB["Subnet in a virtual network"]
    NIC --> PIP["Public IP (optional)"]
    NIC --> NSG["Network security group"]
    VM -.-> EXT["Extensions (agents, scripts)"]

When you delete the VM, some of these pieces can stay behind (and keep billing you) unless you told Azure to delete them along with the VM. Deleting the whole resource group is the cleanest way to tidy up a lab.

Decoding VM size names

Azure size names look like line noise at first, but they follow a pattern. Microsoft’s VM naming conventions page describes it as:

Family + sub-family (optional) + number of vCPUs + constrained vCPUs (optional) + additive features + accelerator type (optional) + version

Let’s take Standard_D4ads_v5 apart:

The most common additive feature letters you’ll meet:

• a: AMD processor. p: Arm-based processor. No a or p usually means Intel.
• d: has a local temporary disk.
• s: supports premium storage.
• l: lower memory than the standard ratio for that family. m: more memory. t: tiny memory.
• i: isolated size (the VM gets the whole physical host).
• b: higher block storage performance.

So Standard_D4ps_v6 would read as “general purpose, 4 vCPUs, Arm processor, premium storage capable, version 6”. Older sizes (such as some D and A sizes) predate this scheme and don’t follow it neatly, so always check the size’s own documentation page before relying on the name alone.

The VM families: pick by workload

Azure groups sizes into families, each tuned for a kind of workload. You don’t need to memorise every series; you need to know which shelf to look on.

flowchart LR
    Q{"What does the workload need most?"}
    Q -->|"A balance of CPU and RAM"| GP["General purpose: B, D"]
    Q -->|"Lots of CPU"| CO["Compute optimized: F"]
    Q -->|"Lots of RAM"| MO["Memory optimized: E, M"]
    Q -->|"Fast local storage"| SO["Storage optimized: L"]
    Q -->|"GPUs"| GPU["GPU: N family"]
    Q -->|"Tightly coupled HPC"| HPC["High performance compute: H"]

A note on the B-series

The B-series is “burstable”. It’s designed for workloads that sit mostly idle and occasionally spike, like a small dev server or a low-traffic site. While the VM runs below its baseline CPU level it banks credits, and it spends those credits when it needs to burst above the baseline. If the credits run out, performance drops back to the baseline. Great for cheap lab machines; a poor fit for anything that runs hot all day.

How to choose without guessing

1. Start with general purpose (D-series) unless you already know the workload is CPU-, memory- or GPU-heavy.
2. Pick the smallest size that fits, then watch CPU and memory metrics in Azure Monitor for a week.
3. Resize up or down. Resizing usually means a restart, so plan it for a quiet moment.
4. Check that the size you want is actually offered in your region. Not every size exists everywhere.

You can ask the Azure CLI what’s available in a region:

# List VM sizes available to your subscription in Canada Central
az vm list-skus --location canadacentral --resource-type virtualMachines --output table

Storage: managed disks

Every Azure VM has an OS disk, and most sizes also come with a temporary disk (the d in the size name). You can add data disks for anything you want to keep.

The golden rule: the temporary disk is scratch space. Its data can be lost when the VM is moved to another host, for example during maintenance, a resize, or after a deallocation. Never keep anything there you can’t afford to lose; use it for page files, swap and caches.

The OS and data disks are managed disks: Azure stores and replicates them for you, and you choose a performance tier. Microsoft currently offers five managed disk types:

Two details worth knowing:

• Premium SSD v2 gives every disk a free baseline of 3,000 IOPS and 125 MB/s, and you can raise IOPS and throughput independently of the disk size. Handy when you need speed but not capacity.
• Microsoft has announced that using Standard HDD as an OS disk will be retired on September 8, 2028, so don’t build new long-lived VMs on it.

Networking in one breath

Every VM’s network interface sits in a subnet inside a virtual network (VNet). A network security group (NSG) acts as a stateful firewall on the NIC, the subnet, or both.

A few practical habits:

• Don’t open SSH (22) or RDP (3389) to the whole internet. Use Azure Bastion for browser-based access, or restrict the NSG rule to your own IP address.
• Plan outbound internet access explicitly. Microsoft has been retiring “default outbound access” for VMs in new virtual networks, so new setups should use a NAT gateway, a load balancer outbound rule, or a public IP when the VM needs to reach the internet. Check the default outbound access docs for how this affects your VNets.
• Identity matters as much as the network. Give the VM a managed identity so your code can reach storage or Key Vault without passwords in config files. Our Azure IAM and Microsoft Entra ID article explains the roles side.

Staying up: availability options

Hardware fails, and Microsoft patches hosts. Azure gives you a few ways to stop a single failure from taking your app down. They build on the regions and zones we covered in Azure Global Infrastructure.

flowchart TB
    subgraph Region["Azure region"]
        subgraph Z1["Zone 1"]
            V1["VM 1"]
        end
        subgraph Z2["Zone 2"]
            V2["VM 2"]
        end
        subgraph Z3["Zone 3"]
            V3["VM 3"]
        end
    end
    LB["Load balancer"] --> V1
    LB --> V2
    LB --> V3
    Users["Users"] --> LB

Some terms worth unpacking:

• A fault domain is a group of hardware that shares power, cooling and networking. An availability set uses up to 3 fault domains.
• An update domain is a group of hosts that can be restarted together during planned maintenance. An availability set can have up to 20.
• Virtual Machine Scale Sets with Flexible orchestration are what Microsoft now recommends for high availability with the widest range of features. They can spread VMs across zones and fault domains for you.

Rule of thumb: if the app matters, run at least two VMs behind a load balancer and spread them across zones. We’ll dig into scaling in a later article in this series.

Power states and your bill

This is where many first Azure bills go wrong. “Stopped” doesn’t always mean “free”.

stateDiagram-v2
    [*] --> Running: Start
    Running --> Stopped: Shut down from inside the OS
    Running --> Deallocated: Stop in portal or az vm deallocate
    Stopped --> Deallocated: az vm deallocate
    Stopped --> Running: Start
    Deallocated --> Running: Start
    Deallocated --> [*]: Delete

• Running: you pay for compute.
• Stopped: the OS is off, but the VM still holds its spot on the host, so compute billing continues. This is what you get from shutdown inside Linux or “Shut down” in Windows, and from az vm stop.
• Stopped (deallocated): the host is released and compute billing stops. Disks (and a static public IP, if you have one) still cost money.

The CLI makes the difference explicit:

# Powers off the VM but keeps it allocated: you keep paying for compute
az vm stop --resource-group rg-demo --name vm-demo

# Releases the hardware: compute charges stop
az vm deallocate --resource-group rg-demo --name vm-demo

# Check the power state
az vm get-instance-view --resource-group rg-demo --name vm-demo \
  --query "instanceView.statuses[?starts_with(code, 'PowerState/')].displayStatus" --output tsv

The portal’s Stop button deallocates, which is usually what you want for a lab machine. You can also set auto-shutdown on a VM so it deallocates every evening.

Ways to pay

Azure offers several pricing approaches for the same VM. We’ll compare them across all three clouds in a later article, but here’s the Azure lineup:

Prices vary by region, size and OS, so always check the Azure pricing calculator rather than trusting numbers in a blog post (including this one!). Our Azure Free Tier and Billing Overview shows how to set budgets and alerts so nothing surprises you.

Spot VMs in practice

Spot VMs come with an eviction policy:

• Deallocate (the default): the VM is stopped and deallocated. You can try to start it again later, but capacity isn’t guaranteed, and you still pay for its disks.
• Delete: the VM and its disks are deleted, so storage billing stops too.

Azure can give a warning through Scheduled Events on a best-effort basis, up to about 30 seconds before eviction. That’s not much time, so Spot workloads should save their progress regularly instead of relying on the warning.

Hands-on: build one from the CLI

Here’s a small, cheap Linux VM built entirely from the Azure CLI, using a verified image alias. Run it in Azure Cloud Shell or a local az install.

# 1. A resource group to hold everything
az group create --name rg-vm-demo --location canadacentral

# 2. The VM: a small burstable size, SSH keys, Standard SSD OS disk
az vm create \
  --resource-group rg-vm-demo \
  --name vm-demo \
  --image Ubuntu2204 \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --storage-sku StandardSSD_LRS \
  --public-ip-sku Standard

# 3. Open SSH (22) in the VM's network security group
az vm open-port --resource-group rg-vm-demo --name vm-demo \
  --port 22 --priority 1000

# 4. Done for the day? Deallocate to stop compute charges
az vm deallocate --resource-group rg-vm-demo --name vm-demo

# 5. Done for good? Delete everything in one go
az group delete --name rg-vm-demo --yes --no-wait

Note that az vm open-port opens the port to any source by default. In anything beyond a throwaway lab, edit the NSG rule afterwards to allow only your IP address, or use Azure Bastion instead.

To see which sizes you could resize this VM to without moving it:

az vm list-vm-resize-options --resource-group rg-vm-demo --name vm-demo --output table

How Azure VMs compare at a glance

If you’ve read the earlier articles in this series, here’s how the vocabulary lines up:

The next article in the series puts all three side by side in much more detail.

Further reading

• Azure Virtual Machines overview
• Sizes for virtual machines in Azure
• Azure managed disk types
• Availability options for Azure VMs
• Use Azure Spot Virtual Machines
• On this site: Introduction to Microsoft Azure and Navigating the Azure Portal

Key takeaways

• An Azure VM is a bundle of resources (VM, disks, NIC, public IP, NSG) in a resource group; clean up the whole group, not just the VM.
• Size names follow a pattern: family, vCPUs, feature letters (like a for AMD, d for local temp disk, s for premium storage) and a version.
• Pick the family by workload: B/D general purpose, F compute, E/M memory, L storage, N GPU, H HPC. Start small and resize based on metrics.
• The temporary disk is scratch space. Keep real data on managed disks, choosing Premium SSD, Premium SSD v2 or Ultra Disk for demanding work.
• For resilience, run multiple VMs across availability zones, ideally with Virtual Machine Scale Sets in Flexible mode.
• “Stopped” still bills compute; “Stopped (deallocated)” doesn’t. Use the portal Stop button or az vm deallocate.
• Mix pay-as-you-go, Reservations, savings plans, Spot VMs and Azure Hybrid Benefit to match how each workload actually runs.