Virtual Machines & availability
Sizing, availability sets/zones, VM Scale Sets.
A virtual machine (VM) is the most literal thing in the cloud: a computer someone else owns, in a building you will never visit, rented to you by the minute. Everything about running VMs follows from one uncomfortable fact. Your rented computer sits on a physical server, in a physical rack, in a physical building, and all three can break. Renting apartments for your business is the closest everyday version of the problem. The size you pick is the floor plan. Availability is deciding whether everything sits in one unit (a fire takes the lot), or across units wired to different electrical risers in the same building (a blown circuit takes one), or across buildings in different parts of town (a neighborhood blackout leaves you running). Azure has a named construct for each of those levels, each one buys a different guarantee, and the AZ-104 exam asks which is which over and over.
What you're actually renting
VMs are Azure's flagship IaaS product. IaaS stands for *infrastructure as a service*, and the apartment analogy carries it: the landlord owns the building, the wiring and the plumbing. Here that means Microsoft runs the hardware, the hypervisor (the software that carves one physical server into many virtual ones) and the physical network. You own everything from the operating system upward. Patching, hardening, backups, capacity planning, all yours. That is the whole trade. Maximum control, maximum chores. Every VM boots from a managed disk, which is block storage that Azure replicates and repairs on your behalf, and those disks climb in speed and price: Standard HDD (a spinning hard disk), Standard SSD (solid state, no moving parts), Premium SSD, Premium SSD v2, and Ultra Disk.
A VM's size is written as a SKU name (stock keeping unit, the same kind of product code a supermarket prints on a shelf tag), and you want to read it at a glance. Standard_D4s_v5 breaks apart like this: D is the family (general purpose, a balanced ratio of CPU to memory), 4 is the vCPU count (virtual CPUs, slices of the host's processors), s means the size can attach Premium SSD disks, and v5 is the hardware generation. The other families you meet daily: B is burstable, banking CPU credits while the machine idles and spending them under load, which is cheap for a dev box and painful for anything under steady traffic. E is memory-optimized, F is compute-optimized, N carries GPUs (graphics processors, used for machine learning and rendering). Right-sizing means matching the SKU to utilization you have actually *measured*, not the number someone guessed in a planning meeting. It is the biggest cost lever you have, because an oversized VM charges the same whether it works flat out or waits all day.
# Resource group first, then the VM — pinned to availability zone 1az group create --name rg-web-prod --location eastus2az vm create \--resource-group rg-web-prod \--name vm-web-01 \--image Ubuntu2204 \--size Standard_D2s_v5 \--zone 1 \--admin-username azureuser \--generate-ssh-keys \--public-ip-sku Standard# ~90 seconds later:{"fqdns": "","id": "/subscriptions/0b1f6471-.../resourceGroups/rg-web-prod/providers/Microsoft.Compute/virtualMachines/vm-web-01","location": "eastus2","macAddress": "60-45-BD-8A-1C-F2","powerState": "VM running","privateIpAddress": "10.0.0.4","publicIpAddress": "20.114.82.107","resourceGroup": "rg-web-prod","zones": "1"}
Look at what that single line of the az command line tool really built: the VM, a NIC (network interface card, the machine's virtual network adapter), a public IP address (internet protocol address, the number the internet reaches it on), an NSG (network security group, Azure's firewall rule list), an OS disk, and a virtual network if none existed yet. Six resources from one command. The convenience bites back at teardown, because az vm delete removes the VM and nothing else by default, leaving orphaned disks and IP addresses billing quietly in the background. In production you either pass --os-disk-delete-option Delete at creation time, or you delete the whole resource group and take everything with it.
The uptime ladder: what sets and zones actually survive
An SLA (service level agreement) is Azure's uptime promise with money behind it. Miss the number and Microsoft owes you service credits. For VMs that promise depends entirely on how you deploy, not on which machine you buy. Inside one datacenter, hosts are grouped into fault domains. A fault domain is a rack sharing one power feed and one network switch, so a single failure takes down every host in it. Update domains are a separate grouping: batches of hosts that Azure reboots together during planned maintenance. An availability set is a container you assign when the VM is created, and it spreads your machines across up to 3 fault domains and up to 20 update domains, so neither a dead rack nor a maintenance wave can catch all of them at once. Two or more VMs in a set earn a 99.95% SLA.
A set still lives in *one building*. An availability zone is a physically separate location inside the same region, one or more datacenters with their own power, cooling and network feeds, far enough apart that a single flood or substation failure will not take both. Two or more VMs spread across two or more zones earn 99.99%. A lone VM gets 99.9%, and only if every disk attached to it is Premium SSD, Premium SSD v2 or Ultra Disk. Three exam details worth burning into memory: a VM cannot sit in a set and a zone at the same time; a VM cannot *join* a set later, it has to be born into one; and a set defends you against hardware failure, never against losing the datacenter. When a question says "survive a datacenter outage," the answer is zones, full stop.
# Availability set: 3 fault domains, 5 update domainsaz vm availability-set create \--resource-group rg-web-prod \--name avset-web \--platform-fault-domain-count 3 \--platform-update-domain-count 5# VMs must be created INTO the set — you cannot move one in lateraz vm create -g rg-web-prod -n vm-web-02 --image Ubuntu2204 \--size Standard_D2s_v5 --availability-set avset-web \--admin-username azureuser --generate-ssh-keys# Zone spread: same VM shape, different zone (no set allowed here)az vm create -g rg-web-prod -n vm-web-03 --image Ubuntu2204 \--size Standard_D2s_v5 --zone 2 \--admin-username azureuser --generate-ssh-keys# Verify placementaz vm list -g rg-web-prod --query "[].{name:name, zone:zones[0]}" -o table# Name Zone# --------- ------# vm-web-01 1# vm-web-02 <- in avset-web, zones column empty# vm-web-03 2
Scale sets: capacity that follows demand
Sets and zones buy survival. Neither buys elasticity. A Virtual Machine Scale Set (VMSS) is a cookie cutter plus a number: you describe the VM shape once, say how many you want, and Azure stamps out identical instances, spreads them across zones and fault domains, and swaps out sick ones on its own once you switch on automatic instance repairs and give it a health signal to watch. Attach an autoscale policy and the count follows the traffic. Two orchestration modes exist. *Uniform* is the classic one, where instances are identical and handled as a single block. *Flexible* treats each instance as an ordinary VM you can manage individually, and even mix sizes inside, which is the default and the recommendation in current tooling. Autoscale is not a property of the scale set. It is a separate Azure Monitor resource you attach to it, and the exam loves questions built on exactly that distinction.
# Scale set across all three zones, behind a Standard load balanceraz vmss create \--resource-group rg-web-prod \--name vmss-web \--image Ubuntu2204 \--vm-sku Standard_D2s_v5 \--orchestration-mode Flexible \--instance-count 2 \--zones 1 2 3 \--admin-username azureuser \--generate-ssh-keys# returns JSON ending in: "provisioningState": "Succeeded"# Autoscale profile: floor of 2, ceiling of 10az monitor autoscale create \--resource-group rg-web-prod \--resource vmss-web \--resource-type Microsoft.Compute/virtualMachineScaleSets \--name autoscale-web \--min-count 2 --max-count 10 --count 2# Out fast, in slow — asymmetry is deliberateaz monitor autoscale rule create -g rg-web-prod \--autoscale-name autoscale-web \--condition "Percentage CPU > 70 avg 5m" --scale out 2az monitor autoscale rule create -g rg-web-prod \--autoscale-name autoscale-web \--condition "Percentage CPU < 30 avg 10m" --scale in 1
Read those two rules again. Scale *out* by 2 after five minutes above 70% CPU. Scale *in* by 1, and only after ten calm minutes below 30%. The lopsidedness is deliberate. It stops flapping, where instances churn up and down around the threshold, which costs money and drops live connections every time one disappears mid-request. Add capacity fast. Take it away slowly.
az vm stop, leaves it in the *stopped* state. The host hardware is still being held for you, and compute billing carries on at the full rate. It is the hotel room you walked out of without checking out. Only az vm deallocate hands the room back and stops the compute meter (disks and static IP addresses keep billing either way). Two side effects to keep in your head. Deallocating releases any *dynamic* IP address, so a legacy Basic-SKU dynamic public IP (that SKU retired for new deployments in September 2025, and Standard SKU public IPs are static) comes back as a different address when the machine restarts. And B-series VMs forfeit every CPU credit they had banked. Teams have burned thousands of dollars on fleets of "switched off" VMs that were only ever stopped.Day-to-day: power state, resizing, and cost
Most days as an administrator come down to three questions. What is running? Is it the right size? What can be switched off? Resizing is a genuine reboot, because Azure has to move the machine onto hardware that fits the new size, and not every size is available on the cluster your VM currently sits on. az vm list-vm-resize-options shows what you can reach while it is live, and deallocating first widens the menu to anything the region offers. Inside an availability set it gets stricter. If the new size is not available on the cluster hosting the set, every VM in that set has to be deallocated so the group can move together. Book resizes into a maintenance window. They are not a hot fix.
az vm list -g rg-web-prod --show-details \--query "[].{name:name, power:powerState, size:hardwareProfile.vmSize}" -o table# Name Power Size# --------- ---------- ---------------# vm-web-01 VM running Standard_D2s_v5# vm-web-02 VM running Standard_D2s_v5# vm-web-03 VM running Standard_D2s_v5# Release the compute lease (billing for compute stops)az vm deallocate -g rg-web-prod -n vm-web-01# What can this VM become?az vm list-vm-resize-options -g rg-web-prod -n vm-web-01 \--query "[?contains(name,'D4s')].name" -o tsv# Standard_D4s_v3# Standard_D4s_v4# Standard_D4s_v5# Standard_D4s_v6az vm resize -g rg-web-prod -n vm-web-01 --size Standard_D4s_v5az vm start -g rg-web-prod -n vm-web-01
Total control is a job, and VMs hand you all of it. You patch the operating system every month or an attacker eventually does it for you. You design the availability layout yourself. You pay for every allocated second, whether the CPU is working or waiting. A zone-spread scale set behind a load balancer is the sturdiest thing you can build out of raw VMs, and for a plain web app or an API it is still a pile of engineering nobody is paying you for. The next lesson climbs one rung to App Service and Functions, where Microsoft takes back the operating system, the patching and the scaling logic you wired by hand here, and you ship code instead of infrastructure. Knowing both layers, and knowing when each one is the wrong answer, is what separates an administrator from someone who memorized the portal.
A VM in Azure is a lease on compute, and the disks, the network card and often a public IP address ride along with that lease. az vm deallocate, or stopping the machine from the portal, ends the lease and stops the meter for the size. A shutdown from inside the guest operating system does not, which is how you end up paying full price for a machine that looks "off" in every dashboard. Availability is a placement decision you make at create time: sets for fault and update domains inside one datacenter, zones for separate buildings across the region.
VM Scale Sets (VMSS) are the fleet version of the same idea: identical instances, autoscale rules, and rolling upgrades when the image changes. For AZ-104, be clear about when one VM is plenty (a lab box, a jump host) and when you need a set or a scale set (anything serving real users). Whatever you build, pair the compute with network security groups, and reach it through Azure Bastion or JIT access (a short, time-limited window where Microsoft Defender for Cloud opens the management port only when you ask, then shuts it again) instead of leaving SSH (secure shell, the Linux remote terminal protocol) or RDP (remote desktop protocol, the Windows equivalent) open on a public IP address forever.
Try this
Build a small Linux VM in a throwaway resource group, check whether it landed in a zone or a set, then stop it and watch the difference between stopped and deallocated show up in what you are billed.
RG=rg-lab-vmaz group create -n $RG -l eastusaz vm create -g $RG -n vm-lab-01 --image Ubuntu2204 --size Standard_B1s \--admin-username azureuser --generate-ssh-keys --public-ip-sku Standardaz vm show -g $RG -n vm-lab-01 --query "{size:hardwareProfile.vmSize, zones:zones, power:provisioningState}" -o jsonaz vm get-instance-view -g $RG -n vm-lab-01 --query "instanceView.statuses[1].displayStatus" -o tsv
$ az vm show -g rg-lab-vm -n vm-lab-01 --query "{size:hardwareProfile.vmSize, zones:zones}" -o json{"size": "Standard_B1s","zones": null}# Sample output$ az vm get-instance-view -g rg-lab-vm -n vm-lab-01 --query "instanceView.statuses[1].displayStatus" -o tsvVM running
Takeaway
Four lines to keep. Size picks CPU, memory and price. Availability sets survive a dead rack. Availability zones survive a dead datacenter. Scale sets add identical capacity behind a load balancer and hand it back when the traffic goes home.
Next: put two VMs in different zones behind a load balancer, then kill one on purpose. Traffic should keep flowing through the survivor without you touching anything.