Azure Virtual Machines: Sizes, Disks, and Zones (AZ-104)

Creating an Azure virtual machine comes down to a handful of decisions that the portal, Azure CLI, Azure PowerShell and ARM/Bicep templates all ask for. Most can be changed later; a few cannot, so they are the ones to get right first.

• Image — the operating system and any pre-installed software, such as Windows Server 2022 or Ubuntu Server, either from the Marketplace or from your own custom image (covered below). The image is the starting point for the OS disk.
• Size — the combination of vCPUs and memory (and sometimes GPUs or fast local storage) that sets performance and price. Sizes are grouped into families, covered later.
• Authentication — a username plus password for Windows; an SSH public key (recommended) or a password for Linux.
• Resource group and region — the management container, and the location where the VM runs; pick a region close to users that offers the sizes and zones you need.
• Availability option — no redundancy, an availability zone, a virtual machine scale set, or an availability set.
• Security type — Standard, Trusted launch (Secure Boot and vTPM, the default for supported images) or Confidential VM.
• OS disk — its disk type, and whether it is a normal persistent managed disk or an ephemeral OS disk.

Behind the scenes, creating a VM also creates supporting resources: the OS disk, a network interface (NIC) that connects the VM to a subnet, and usually a public IP. The deeper virtual network and network security group configuration belongs to the networking domain.

What you can and cannot change later. The settings below are worth checking before you select Create.

The recommended way to sign in to a Linux VM is SSH public key authentication, chosen when the VM is created. You give Azure only the public key; the private key never leaves the client, and when you choose SSH key authentication at creation, password sign-in is disabled, so the key pair is the only way in.

At creation the portal offers three sources for the key: generate a new key pair (Azure stores the public key and lets you download the private key once), use an existing key stored in Azure (an SSH key resource), or use an existing public key that you paste in — the right choice when a team already holds its own key pair.

For Windows VMs the equivalent creation-time choice is the local administrator username and password; Entra ID sign-in for Windows uses the AADLoginForWindows extension. Network paths to the VM (Azure Bastion, VPN) are covered in the networking domain.

You configure the inside of a VM at creation time, without signing in, by passing a first-boot configuration or a script extension; you create many identical VMs by deploying from a generalized custom image.

cloud-init (Linux). Most Linux Marketplace images run cloud-init on first boot. You supply a declarative cloud-config file (install packages, create users, write files, run commands) as the VM's custom data on the Advanced tab, with --custom-data in Azure CLI, or in a template. Windows stores custom data on the disk but does not execute it.

Custom Script Extension (Windows and Linux). The Custom Script Extension downloads scripts from URIs — for example a storage account or GitHub — and runs them inside the VM through the Azure VM agent. Because it is an ARM resource (Microsoft.Compute/virtualMachines/extensions), it is the standard way to run post-deployment configuration from a template, for any number of VMs, with nobody signing in.

Custom images. To build many VMs from a configured reference machine, first generalize it so each new VM gets its own identity: run Sysprep with the generalize option (and shut down) on Windows, or waagent -deprovision+user on Linux. A generalized source VM cannot be started and used again. Capture the image into an Azure Compute Gallery: a gallery holds image definitions, each with numbered image versions that you replicate to the regions where VMs will be deployed, and you share the gallery or definition with Azure RBAC. A gallery can also hold specialized images (not generalized), which keep the source machine's identity and are meant for cloning a single machine rather than mass deployment.

Azure Spot Virtual Machines run on spare Azure capacity at a deep discount, in exchange for no availability SLA and the risk of eviction. They suit interruptible work that can stop and resume — batch jobs that checkpoint, rendering, CI build agents, dev/test — and never a workload that must stay up.

• Eviction for capacity — Azure takes the VM back whenever it needs the capacity. This can always happen.
• Eviction for price — you can set a maximum price per hour; if the current Spot price rises above it, the VM is evicted. A max price of -1 means "pay up to the standard pay-as-you-go price" — the VM is then never evicted for price, but it can still be evicted for capacity.
• Eviction policy — Deallocate (the default: the VM stops, its disks remain and are still billed, and you can try to start it later) or Delete (the VM and its disks are removed).

Spot pricing is chosen on the Basics tab when you create the VM. Compare it with reservations and savings plans, which discount steady, always-on usage and keep the normal SLA. In a scale set, Spot and regular VMs can be mixed with Spot Priority Mix (see the scale set section).

A VM's size sets its vCPUs, memory and other characteristics, and Azure groups sizes into families tuned for different workloads. Matching a workload profile to a family is a common exam task.

Other families cover GPUs (N-series), very large memory (M-series) and high-performance computing (H-series). The pattern to remember: B and D balance CPU and memory, F gives more CPU per gigabyte, E gives more memory per vCPU, and L adds fast local storage. A B-series VM whose load stays high all the time runs out of credits and drops to its baseline — steady high CPU belongs on D or F.

Resizing is done from the VM's Size blade, Azure CLI (az vm resize) or PowerShell, and always restarts the VM. On a running VM, the Size list shows only the sizes available on the hardware cluster the VM currently runs on. If the size you need is offered in the region and you have quota but it is missing from the list, stop (deallocate) the VM: deallocation releases the cluster, and every size in the region then appears. A restart does not help, because a restarted VM stays on the same cluster.

Availability sets add a constraint. All VMs in an availability set share one cluster. If the target size is not available on that cluster, deallocating only the VM you are resizing is not enough — you must deallocate every VM in the set, resize, and start them again. Also check that the new size supports the disk types and the number of data disks already attached.

Every VM has an OS disk that boots the machine, usually a temporary disk, and as many data disks as its size allows. Azure VM disks are managed disks: Azure handles the storage account, replication and availability, and you pick a type and a size.

Choose the cheapest tier that meets the need: Standard HDD when cost beats speed, Premium SSD for most production work, Premium SSD v2 when you want to raise IOPS or throughput later without resizing the disk, and Ultra Disk only when a single disk must go beyond what Premium SSD v2 offers. Neither Premium SSD v2 nor Ultra Disk can be an OS disk.

Adding and growing data disks. You can attach a new or existing data disk to a running VM without a restart. The disk then appears to the guest as raw storage: you must initialize, partition and format it inside the OS (Disk Management on Windows; partition, mkfs and an /etc/fstab entry on Linux) before applications can use it. The maximum number of data disks is set by the VM size — to attach more, resize to a larger size. You can expand a disk to a larger size (then extend the partition inside the guest), but you can never shrink one. Changing a disk's type, for example Standard SSD to Premium SSD, requires the VM to be deallocated.

Host caching is available on Standard HDD, Standard SSD and Premium SSD disks (not on Premium SSD v2 or Ultra Disk) and tunes performance: ReadOnly suits read-heavy database data disks, None suits write-heavy log disks, and the OS disk defaults to ReadWrite.

The temporary disk (drive D: on many Windows sizes, /dev/sdb1 or /mnt on Linux) is storage local to the physical host, not a managed disk. Its contents survive a normal reboot but are lost when the VM is deallocated, redeployed, or resized onto different hardware, because the VM then lands on a new host. Use it for page files and scratch data only.

Ephemeral OS disks put the OS disk on that same local storage — the VM's cache disk, temp disk or NVMe disk placement — instead of in Azure Storage. They give lower OS-disk latency, faster reimage and no OS-disk storage cost, which suits stateless VMs and scale set instances rebuilt from an image. The trade-offs: anything written to the OS disk is lost on reimage or host change, the VM does not support stop-deallocate, and you can choose an ephemeral OS disk only when the VM is created.

A single VM depends on one host, so Azure offers two ways to spread VMs so a fault affects only part of a workload: availability zones across datacenters, and availability sets inside one datacenter. Telling them apart is one of the most tested comparisons in this domain.

Availability zones are physically separate datacenters within one Azure region, each with independent power, cooling and networking. Deploying two or more VMs across two or more zones survives the loss of a whole datacenter and qualifies for a 99.99% VM SLA. A single zonal VM is still in one datacenter: its LRS managed disks are created in the same zone, so the zone setting alone does not make it resilient. Put the VMs behind a load balancer whose frontend is zone-redundant (served from every zone) rather than zonal (tied to one zone), so the entry point also survives a zone failure.

Availability sets protect against smaller failures within a single datacenter. Azure spreads the set's VMs across fault domains (racks that share power and a network switch, so one rack failure hits only one domain) and update domains (groups that Azure reboots one at a time during planned platform maintenance). Two or more VMs in a set qualify for a 99.95% SLA. Membership is decided at creation: an existing VM cannot be added to a set without recreating it. A VM is either zonal or in an availability set — the two options are mutually exclusive. Availability sets remain the right choice in regions without zones.

Read the requirement: survive a datacenter failure or the 99.99% SLA means zones; protection from rack failures and patching in one datacenter, or a region with no zones, means an availability set.

Consider a concrete decision. Your team runs a customer-facing web application on two Azure VMs behind a load balancer, and the business wants the strongest single-region availability the platform can offer, with resilience to a complete datacenter outage. Which placement do you choose?

An availability set would protect the two VMs from a rack failure or a maintenance reboot, but every VM in the set lives in the same datacenter. If that datacenter lost power, both VMs — and your web tier — would go down, and the set only carries a 99.95% SLA.

The right answer is availability zones. Deploy VM 1 into zone 1 and VM 2 into zone 2 of the same region. The two zones are physically separate datacenters with independent power, cooling, and networking, so an outage in one zone leaves the other serving traffic. This configuration qualifies for the 99.99% VM SLA, the highest single-region guarantee, and directly meets the "survive a datacenter failure" requirement. Front the zonal VMs with a Standard load balancer whose frontend is zone-redundant, so the public entry point keeps answering and requests flow to whichever zone is healthy — a zonal frontend pinned to zone 1 would fail with that zone.

The lesson generalises: when a scenario stresses surviving a whole-datacenter failure or names the 99.99% SLA, choose availability zones; when it only needs protection from rack failures and patching within one datacenter, an availability set is enough. For a fleet that also needs to scale, the next section introduces scale sets.

A Virtual Machine Scale Set (VMSS) runs a group of load-balanced VM instances from one model and can add or remove instances automatically. Use one when a stateless tier needs many identical VMs that grow and shrink with demand; a scale set can also spread instances across availability zones and fault domains.

Orchestration mode is chosen at creation:

Spot Priority Mix (Flexible only) keeps a ratio of regular and Spot VMs as the set scales: baseRegularPriorityCount is the number of instances that are always regular priority, and regularPriorityPercentageAboveBase is the share of regular VMs in all capacity above that base — the rest are Spot.

Upgrade policy decides how instances pick up a changed scale set model, such as a new image version:

• Manual — nothing changes until you update instances yourself.
• Automatic — instances are updated without waiting, in no guaranteed order, so they can be down at the same time.
• Rolling — instances are updated in batches, with optional pauses, and the upgrade stops if upgraded instances turn unhealthy. It needs a health signal: the Application Health extension on Flexible scale sets, and either that extension or a load balancer health probe on Uniform scale sets.

Autoscale (Azure Monitor autoscale) works through profiles. The default profile applies when nothing else does; a recurring profile applies on a weekly schedule (for example weekdays 08:00–18:00); a fixed-date profile applies for one date range, such as a sale event. Only one profile is active at a time, and each has its own minimum, maximum and default instance count and its own rules — rules are not inherited from the default profile. A scheduled profile with no rules never reacts to load and holds the instance count at its minimum. Each rule pairs a metric condition (such as average CPU above 70% over 10 minutes) with an action and a cool-down; always pair scale-out rules with scale-in rules so capacity also falls.

Azure managed disks are always encrypted at rest — by default through server-side encryption (SSE) in Azure Storage, or on the host itself when encryption at host is on; the other options add coverage or control on top. The exam tests which option covers which data and where the encryption runs.

Encryption at host encrypts data on the Azure host the VM runs on, so the temp disk and caches — which are not managed disks and which SSE never sees — are encrypted, and disk data is already encrypted when it flows into Azure Storage (such disks are encrypted by the host rather than by Storage). One exception to know: VM sizes of version 5 and later (for example Dsv5 or Dsv6) encrypt their temp disk and any ephemeral OS disk at rest automatically; on older sizes the temp disk is unencrypted unless encryption at host is on. Microsoft recommends it, rather than ADE, for new VMs. Caches and the host-to-storage flow use the same key type as the disk's SSE (platform- or customer-managed); the temp disk and ephemeral OS disk always use platform-managed keys.

To enable it:

1. Register the feature once per subscription: az feature register --namespace Microsoft.Compute --name EncryptionAtHost (or Register-AzProviderFeature), then wait for the state to read Registered. Until then, deployments that request it are rejected.
2. Choose a VM size that supports encryption at host.
3. Set it on the VM (Disks tab, --encryption-at-host true, or securityProfile.encryptionAtHost in a template). For an existing VM, deallocate it first, enable the setting, then start it.

A VM that has ever had Azure Disk Encryption enabled cannot use encryption at host — the two are not combined. Choose ADE only when a requirement explicitly needs encryption performed by the guest OS with BitLocker or dm-crypt, and plan for its 2028 retirement.

Moving a VM to another resource group or subscription is a native Azure Resource Manager move; moving it to another region uses Azure Resource Mover. Confusing the two is a classic exam trap.

Resource group or subscription

Select the VM with its dependent resources — disks, NIC, public IP — choose Move, and pick the destination; Azure validates the move first. The VM keeps running, its region does not change (even if the target resource group was created in another region — a resource group's location only stores its metadata), and every moved resource gets a new resource ID, so update scripts, templates and role assignments that reference the old IDs. A subscription move must stay within the same Microsoft Entra tenant.

Special cases:

• Azure Disk Encryption — a VM using ADE with Key Vault can move between resource groups (deallocate it first), but to move it to another subscription you must disable the encryption before the move.
• Azure Backup — delete the VM's restore point collection (the instant-recovery snapshots in the backup resource group) before the move. Recovery points in the Recovery Services vault are kept. If soft delete is on, deleted restore points are retained for 14 days and block the move until they are purged.
• Availability sets — a VM in an availability set cannot be moved on its own; move the availability set together with all of its VMs.
• Customer-managed keys — managed disks encrypted through a disk encryption set with customer-managed keys cannot be moved to another subscription.

Another region with Azure Resource Mover

A region move copies the VM's data to the target region, so you use Azure Resource Mover, which orchestrates the steps in a move collection for one source and one target region:

1. Add resources and resolve dependencies — Resource Mover validates the selection and adds missing dependents (disks, NIC, virtual network, NSG, resource group).
2. Prepare — for a VM, replication to the target region starts.
3. Initiate move — the source VM is shut down and the replica VM is created in the target region, where you test it.
4. Commit move to finish, or Discard move to abandon the attempt: discard removes the replica, keeps the source as the copy of record, and returns the resource to Initiate move pending, so you can retry without preparing again.
5. Delete source resources once the move is committed.

Azure Site Recovery was historically used for region moves; Resource Mover is the purpose-built, recommended tool.