This chapter covers Azure Virtual Machines (VMs), one of the most fundamental IaaS services in Azure. Understanding VMs is critical for AZ-900 because they represent the core compute option and appear in roughly 15-20% of exam questions across multiple domains. You will learn what VMs are, how they work, key configuration choices, pricing models, and common use cases. By the end, you will be able to describe when to use VMs versus other compute services and identify correct VM-related statements on the exam.
Jump to a section
Imagine you run a small furniture business. Instead of buying a building and filling it with tools (an on-premises data center), you rent a workshop from a provider. This workshop is a virtual space: you choose the size (small bench for a few tools, or large warehouse with heavy machinery), the operating system (Windows or Linux workbenches), and the tools pre-installed (software like databases or web servers). You can walk in anytime via remote access (RDP/SSH) and start working. If you need more power for a big order, you can upgrade to a larger workshop in minutes—no need to buy new equipment. When you're done, you stop paying. The provider handles the building's maintenance (hypervisor updates, hardware health). But you are fully responsible for everything inside your workshop: securing the tools, updating software, and cleaning up. This mirrors Azure Virtual Machines: you provision a VM with chosen specs, OS, and software, pay only for what you use (compute + storage), manage the guest OS and apps, and can resize or deallocate as needed. The underlying physical server is abstracted away.
What is an Azure Virtual Machine?
An Azure Virtual Machine is an emulation of a physical computer that runs inside Microsoft's data center. It gives you full control over the operating system (OS) and all installed software, just like a physical server you would manage on-premises. The key difference: you don't own or manage the underlying hardware. Azure takes care of the physical server, networking, and storage infrastructure. You are responsible for everything inside the VM: the OS, applications, security patches, and data.
Business Problem Solved
Before cloud computing, companies had to buy physical servers, wait weeks for delivery, rack them, cable them, install OS and software, and maintain them. This process was slow, capital-intensive, and inflexible. Azure VMs solve this by providing on-demand, pay-as-you-go compute capacity. You can provision a VM in minutes, scale up or down as needed, and only pay for what you use. This is ideal for: - Dev/Test environments: Spin up VMs for testing, then delete them to save costs. - Lift-and-shift migrations: Move existing on-premises applications to Azure without rewriting code. - Disaster recovery: Run VMs in Azure as a backup site. - Extended support: Run legacy OS versions (e.g., Windows Server 2008) that are no longer supported on-premises.
How Azure VMs Work: Step by Step
Hypervisor abstraction: Azure uses a Type 1 hypervisor (Microsoft Hyper-V) that runs on physical servers in Azure data centers. The hypervisor partitions hardware resources (CPU, memory, disk, network) into isolated virtual machines. Each VM has its own virtual CPU, memory, virtual disk, and virtual network interface.
2. VM creation: When you create a VM, you specify: - Size: Number of vCPUs, amount of RAM, and temporary storage (local SSD). Example: Standard_D2s_v3 has 2 vCPUs, 8 GB RAM. - OS image: Windows Server, various Linux distributions (Ubuntu, CentOS, etc.), or a custom image. - Storage: Managed disks (SSD or HDD) for the OS disk and data disks. - Networking: Virtual network (VNet), subnet, public IP (optional), network security group (NSG) rules. - Authentication: Username/password or SSH keys for Linux.
Provisioning: Azure allocates the VM on a physical server, attaches the virtual disks, configures the virtual network interface, and starts the VM. The OS boots from the specified image. This typically takes 2-5 minutes.
Post-deployment: You connect to the VM via RDP (Windows) or SSH (Linux). You then install applications, configure settings, and manage it like any other server.
Key Components of a VM
Virtual CPUs (vCPUs): Each vCPU is a thread on a physical CPU core. Azure offers different VM series optimized for different workloads: General purpose (e.g., D-series), Compute optimized (F-series), Memory optimized (E-series), Storage optimized (L-series), and GPU (N-series).
Memory: RAM allocated to the VM. Must be compatible with the chosen VM size.
Temporary storage: A local SSD attached to the physical server. It is high-speed but ephemeral: data is lost if the VM is moved or deallocated. Use it for page files or tempdb.
Managed disks: Persistent block storage for OS and data. Types: Premium SSD (high performance, low latency), Standard SSD (balanced), Standard HDD (low cost). Disks are replicated three times within an Azure region for durability.
Virtual Network (VNet): Each VM is placed in a VNet and gets a private IP address. You can also assign a public IP for internet access. NSGs act as a firewall to control inbound/outbound traffic.
Availability options: Availability Sets (distribute VMs across fault domains and update domains) and Availability Zones (physically separate data centers within a region) to increase uptime.
Pricing Models
Azure VMs have two main pricing models:
Pay-as-you-go: Pay per second for compute capacity. No upfront commitment. Ideal for short-term or unpredictable workloads.
Reserved Instances (RI): Reserve a VM for 1 or 3 years and get up to 72% discount compared to pay-as-you-go. You commit to a specific VM size and region. Best for steady-state workloads.
Spot VMs: Deeply discounted (up to 90%) but Azure can evict the VM at any time (with 30-second notice) if it needs the capacity back. Suitable for batch processing, dev/test, or fault-tolerant workloads.
Comparison to On-Premises
Capital expenditure: On-premises requires upfront purchase; Azure VM is operational expense.
Scalability: On-premises you buy and install new hardware; Azure you change VM size or add more VMs in minutes.
Maintenance: On-premises you manage hardware lifecycle; Azure handles physical hardware.
Responsibility: On-premises you own everything; Azure VM you share responsibility: Microsoft manages the hypervisor, physical network, and storage infrastructure; you manage the OS, applications, and data.
Azure Portal and CLI Touchpoints
Azure Portal: Navigate to 'Virtual machines' -> 'Create' -> 'Azure virtual machine'. Walk through the wizard: Basics (subscription, resource group, VM name, region, image, size, admin account), Disks (OS disk type, data disks), Networking (VNet, subnet, public IP, NSG), Management (boot diagnostics, auto-shutdown), Advanced (extensions, custom data), Tags, Review + create.
Azure CLI: Example to create a simple Ubuntu VM:
az vm create \
--resource-group myRG \
--name myVM \
--image Ubuntu2204 \
--admin-username azureuser \
--generate-ssh-keysPowerShell:
New-AzVm `
-ResourceGroupName 'myRG' `
-Name 'myVM' `
-Image 'Ubuntu2204' `
-Credential (Get-Credential)Plan VM Requirements
Before creating a VM, determine the workload's compute, memory, storage, and networking needs. For example, a web server might need 2 vCPUs and 4 GB RAM, while a database server may require 8 vCPUs and 32 GB RAM. Choose a VM size from the appropriate series (e.g., D-series for general purpose). Also decide the OS (Windows or Linux) and the region closest to your users. Consider availability requirements: if you need high availability, plan for at least two VMs in an availability set or availability zones. This planning phase prevents costly resizing or redeployment later.
Create Resource Group and VNet
A resource group is a logical container for Azure resources. Create one for your VM and related resources (disks, NIC, public IP). Then create a virtual network (VNet) with a subnet where the VM will reside. The VNet defines the IP address space. For internet access, you will later assign a public IP. Network security groups (NSGs) are created to filter traffic. In the portal, you can create these during VM creation, but pre-planning ensures proper segmentation. For example, place web servers in a front-end subnet and databases in a back-end subnet with NSG rules limiting access.
Provision the Virtual Machine
In the Azure portal, navigate to 'Virtual machines' and click 'Create'. Fill in the basics: subscription, resource group, VM name, region, availability options, image (e.g., Windows Server 2022 Datacenter), size (e.g., Standard_D2s_v3), administrator account (username and password or SSH key). Under 'Disks', choose OS disk type (Premium SSD for production) and optionally add data disks. Under 'Networking', select the VNet and subnet, configure public IP (or none if internal only), and NSG rules (e.g., allow RDP/SSH from your IP). Review and create. Azure deploys the VM and boots the OS.
Connect and Configure the OS
Once the VM is running, connect to it. For Windows VMs, download the RDP file from the portal and use Remote Desktop Connection. For Linux, use SSH with the private key (or password if you chose password auth). After connecting, apply OS updates, install required software (e.g., IIS, SQL Server, custom applications), configure firewall rules inside the OS, and set up monitoring (e.g., Azure Monitor agent). This step is identical to managing an on-premises server, but remember: you are responsible for patching the OS and applications.
Manage and Monitor the VM
After deployment, ongoing management includes: starting/stopping/deallocating the VM (note: deallocated VMs don't incur compute charges but still incur storage costs for disks), resizing (change VM size, which requires a reboot), applying patches, and monitoring performance metrics (CPU, memory, disk I/O) via Azure Monitor. Set up auto-shutdown for dev VMs to save costs. Configure backups using Azure Backup. Enable boot diagnostics to troubleshoot startup issues. Regularly review security recommendations from Azure Security Center.
Scenario 1: Lift-and-Shift Migration of a Legacy Application
A manufacturing company runs a custom inventory management application on a physical Windows Server 2012 R2 server in their on-premises data center. The server is aging, and the company wants to move to the cloud without rewriting the app. They create an Azure VM with Windows Server 2012 R2 (using an image from Azure Marketplace or uploading a VHD), matching the on-premises specs (4 vCPUs, 16 GB RAM, 500 GB disk). They use Azure Site Recovery to replicate the on-premises server to Azure, then perform a test failover. After validation, they cut over production traffic. The VM runs in Azure with a reserved instance to save costs. They set up Azure Backup for daily backups and Azure Monitor for alerts. The migration takes weeks but avoids application changes. Common issues: forgetting to update NSG rules to allow application ports, or not resizing the VM to match workload after migration (leading to performance issues).
AZ-900 Exam Focus: Virtual Machines (Objective 2.2)
What the exam tests: You must be able to describe the benefits and usage of Azure Virtual Machines, including:
Scenarios where VMs are the appropriate compute solution (e.g., custom software, full OS control, lift-and-shift).
The shared responsibility model: Microsoft manages the hypervisor, physical hardware, and storage infrastructure; you manage the OS, applications, and data.
Pricing models: Pay-as-you-go, Reserved Instances, Spot VMs.
Availability options: Availability Sets (fault domains and update domains) vs. Availability Zones.
VM size families and their use cases (general purpose, compute optimized, etc.).
Common wrong answers: 1. "VMs provide a platform-as-service (PaaS) experience" – Wrong. VMs are IaaS. PaaS examples are Azure App Service or Azure SQL Database. 2. "You do not need to patch the OS of a VM" – Wrong. You are responsible for OS patching. 3. "Reserved Instances offer the same discount as Spot VMs" – Wrong. RIs offer up to 72% discount; Spot can be up to 90% but with eviction risk. 4. "Availability Zones are available in all Azure regions" – Wrong. Not all regions support Availability Zones; check region documentation.
Specific terms and values: - SLA for single VM with Premium SSD managed disks: 99.9% (when deployed in an availability set). - SLA for two or more VMs in an availability set: 99.95%. - SLA for VMs in Availability Zones: 99.99%. - Fault domain: a group of VMs that share a common power source and network switch. - Update domain: a group of VMs that can be rebooted together during planned maintenance.
Memory trick: For availability, remember: "1 VM = 99.9%, 2+ in set = 99.95%, zones = 99.99%." For pricing: "Pay as you go = flexible, Reserved = cheap but committed, Spot = cheapest but evictable."
Edge cases: - A VM can be stopped (deallocated) to stop compute charges, but storage charges continue. - Temporary storage (D: drive on Windows, /dev/sdb on Linux) is not persistent; data is lost on deallocation. - You can resize a VM only if the new size is available in the same hardware cluster; sometimes you must deallocate first.
Azure VMs are IaaS, giving you full control over the OS and applications.
You pay for compute (per second while VM is running) and storage (persistent disks).
Reserved Instances offer up to 72% discount for 1- or 3-year commitments.
Spot VMs offer up to 90% discount but can be evicted at any time.
Availability Sets provide 99.95% SLA; Availability Zones provide 99.99% SLA.
Managed disks are replicated three times within a region for durability.
You are responsible for patching the guest OS and applications.
These come up on the exam all the time. Here's how to tell them apart.
Azure Virtual Machines (IaaS)
Full control over OS and applications
You manage OS patches and software updates
You choose VM size and scale manually or with scale sets
Pricing per hour (pay for compute + storage)
Ideal for custom software, legacy apps, or full OS access
Azure App Service (PaaS)
Managed platform; no OS access
Azure manages the OS and runtime environment
Auto-scaling based on rules or metrics
Pricing per plan (based on tier and instance count)
Best for web apps, APIs, and mobile backends
Mistake
Azure VMs are fully managed; Microsoft patches the OS.
Correct
Microsoft manages only the hypervisor and physical hardware. You are responsible for patching the guest OS and applications. Azure does offer automatic OS image updates for some VM scale sets, but not for individual VMs.
Mistake
You can create a VM with any amount of CPU and RAM you want.
Correct
You must choose from predefined VM sizes (e.g., Standard_D2s_v3). You cannot specify arbitrary vCPU and memory combinations. Each size has fixed vCPU count and RAM amount.
Mistake
Stopping a VM stops all charges.
Correct
When you stop (deallocate) a VM, compute charges stop, but you still pay for the managed disks (OS and data disks) and any reserved public IP. Only deleting the VM removes all charges.
Mistake
All Azure regions support Availability Zones.
Correct
Not all regions have Availability Zones. As of 2024, only certain regions (e.g., East US 2, West Europe, Southeast Asia) support them. Always verify region capabilities.
Mistake
Spot VMs are ideal for production workloads.
Correct
Spot VMs can be evicted with 30 seconds notice, so they are not suitable for production workloads that require persistence. They are best for batch processing, dev/test, or stateless applications.
When you 'stop' a VM from within the OS, Azure still allocates resources (compute charges continue). 'Deallocate' releases the compute resources, stopping compute charges. Only deallocated VMs stop compute billing. Use the Azure portal 'Stop' button (which deallocates) or the CLI command `az vm deallocate`. Always use Azure's stop mechanism to deallocate, not the OS shutdown.
Yes, you can resize a VM, but the new size must be available in the same hardware cluster. Sometimes you need to deallocate the VM first. In the portal, go to the VM, select 'Size', and choose a new size. If the size is not available, you may need to deallocate and try again. Note that resizing triggers a reboot.
The SLA for a single VM using Premium SSD managed disks is 99.9% uptime. For two or more VMs in an availability set, the SLA is 99.95%. For VMs in availability zones, the SLA is 99.99%. These SLAs require that all disks are Premium SSD and the VMs are in the same availability set or zone.
General purpose (D-series): balanced CPU-to-memory. Compute optimized (F-series): high CPU-to-memory ratio. Memory optimized (E-series): high memory-to-CPU ratio. Storage optimized (L-series): high disk throughput and IO. GPU (N-series): for graphics and machine learning. Each family has multiple sizes with varying vCPU and RAM.
Yes, Azure supports many Linux distributions including Ubuntu, CentOS, Red Hat Enterprise Linux, SUSE, and Debian. You can choose these images when creating a VM. Linux VMs are billed the same as Windows VMs (compute + storage), but there are no additional licensing costs for Linux OS.
Managed disks are the recommended option. Azure manages the storage account and handles replication, backups, and scaling. Unmanaged disks require you to create and manage storage accounts, which is more complex. Managed disks offer better reliability and simplicity. They are the default in the portal.
Use Reserved Instances for steady-state workloads (1- or 3-year commitment). Use Spot VMs for interruptible workloads. Right-size VMs (monitor utilization and downsize if over-provisioned). Use auto-shutdown for dev/test VMs. Deallocate VMs when not in use. Consider using Azure Hybrid Benefit to use your existing Windows Server or SQL Server licenses.
You've just covered Azure Virtual Machines — now see how well it sticks with free AZ-900 practice questions. Full explanations included, no account needed.
Done with this chapter?