Azure Virtual Machines

An Azure Virtual Machine (VM) is an IaaS offering that provides on-demand, scalable computing resources in the cloud. It emulates a physical computer — with its own CPU, RAM, storage, and network interface — running on Microsoft's hypervisor (Hyper-V) on physical servers in an Azure data centre. You install and manage the guest operating system (Windows or Linux), middleware, and applications, while Azure handles the underlying hardware, host OS, and hypervisor layer.

Creating a VM requires specifying several key parameters: Image — the OS and pre-installed software (e.g., Windows Server 2022, Ubuntu 22.04, SQL Server on Windows). Size — the VM's vCPU count, RAM, and temporary storage (discussed next). Region — where the VM will run. Authentication — SSH key pair for Linux or username/password for Windows. The portal walks you through these settings with guided wizards, and the Azure CLI lets you script the same configuration for repeatable deployments.

Azure organises VM sizes into families (series) optimised for different workloads: B-series (burstable, cost-effective for low average CPU), D-series (general purpose — balanced CPU and memory), E-series (memory optimised for databases and analytics), F-series (compute optimised), N-series (GPU-accelerated for AI/ML and graphics), and L-series (storage optimised). The naming convention encodes the series, vCPU count, and variant — e.g., Standard_D4s_v5 is a D-series VM with 4 vCPUs using premium storage.

Azure offers three pricing models for VMs: Pay-as-you-go — charged per second of compute time, no commitment, highest per-hour rate. Reserved Instances — commit to 1 or 3 years and save up to 72% compared to pay-as-you-go, paid upfront or monthly. Spot Instances — run on unused Azure capacity at discounts of up to 90%, but can be evicted with only 30 seconds notice when Azure needs the capacity back. Spot instances are ideal for batch processing, simulations, and fault-tolerant workloads that can resume from checkpoints.

Every Azure VM has at least two disks: the OS disk (where the operating system is installed, backed by a managed disk) and a temporary disk (fast local SSD for page files and temp data, but data here is LOST when the VM is stopped/deallocated). You can attach additional data disks for application data — these are durable managed disks that persist across VM reboots. Managed disks come in four types: Standard HDD, Standard SSD, Premium SSD, and Ultra Disk, with increasing performance and price.

Each Azure VM is connected to a Virtual Network (VNet) through a virtual network interface card (vNIC). The VM receives a private IP address within the VNet subnet, enabling it to communicate with other resources in the same VNet. To make the VM reachable from the internet, you attach a public IP address and open appropriate Network Security Group (NSG) rules. By default, Azure blocks all inbound internet traffic to a new VM — you must explicitly open ports you need, such as port 22 for SSH or port 3389 for RDP.

To improve VM availability, Azure offers two options: Availability Sets distribute VMs across fault domains (separate racks) and update domains within a single data centre, giving a 99.95% SLA. Availability Zones distribute VMs across physically separate data centres within a region, giving a 99.99% SLA. For new architectures, Microsoft recommends availability zones over availability sets wherever zone support exists, as zones provide stronger isolation against both hardware failures and data centre-level events.

Azure VM Extensions are small applications that automate post-deployment configuration and management tasks on VMs. The Custom Script Extension downloads and runs a script on a VM immediately after creation — useful for installing software or configuring settings without manual SSH/RDP. Other extensions include the Azure Monitor agent (for log collection), Azure Policy guest configuration (for compliance checking), and Antimalware extension (for Windows Defender configuration). Extensions run as the system account and are installed from the Azure portal or ARM templates.

There is an important distinction between stopping and deallocating an Azure VM. Stopping a VM from within the guest OS (e.g., shutdown -h now) shuts down the OS but keeps the VM allocated on the host — you continue to be charged for compute. Deallocating from the Azure portal or CLI releases the underlying compute resources, stopping the compute charge (you still pay for managed disks). Always use az vm deallocate or the 'Stop' button in the portal to avoid unnecessary billing when a VM is not in use.

Azure periodically performs planned maintenance on the host hardware to apply security patches and firmware updates. In most cases, Azure uses live migration to move your VM to updated hardware without rebooting it, causing less than 10ms of network pause. In cases where live migration is not possible, Azure schedules a reboot during a maintenance window and notifies you in advance via the Azure portal and email. You can also self-service schedule the maintenance window for your own VMs through the portal to minimise disruption to your workload.

VMs are the right choice when you need full OS-level control — to install specific OS versions, drivers, or software that cannot run on PaaS platforms. Common use cases include: lift-and-shift migrations of on-premises applications, custom software that requires specific OS configurations, dev/test environments, and legacy applications that cannot be containerised or refactored. When full OS control is not required, consider PaaS options like App Service or Azure Container Instances, which reduce management overhead significantly.

Test your understanding of Microsoft Azure Fundamentals (AZ-900) concepts from this lesson.

In this lesson you learned: Azure VMs are IaaS resources where you manage the guest OS and above, with Azure handling the hypervisor and hardware, VM sizes come in families optimised for general purpose, compute, memory, storage, and GPU workloads, and availability zones provide a 99.99% SLA by distributing VMs across physically separate data centres. Next up we explore Virtual Machine Scale Sets for automatic scaling of identical VMs.