Azure Virtual Machines: What They Are and When to Use Them

What a virtual machine actually is

A virtual machine is an isolated slice of physical server hardware that behaves like a complete computer. It has its own virtual CPU allocation, memory, operating system, storage, and network interface. Multiple VMs run on the same physical host but cannot see or interfere with each other — the hypervisor layer enforces that isolation.

When you create an Azure VM, you choose an image (the operating system and any preinstalled software), a size (CPU and RAM allocation), a region, and a storage configuration. Azure provisions hardware, boots the OS from your chosen image, and gives you a server you can connect to over SSH or RDP within a few minutes.

From that point forward, the VM behaves exactly like a physical server you own. You install packages, configure services, deploy applications, apply OS patches, and manage disk space. Azure keeps the physical host running and the hypervisor healthy — everything inside the VM is your responsibility.

VMs versus managed compute

Azure has five main compute services. They sit on a spectrum from full control to full management:

As you move down the list, you manage less and lose direct OS control. VMs sit at the top — maximum control, maximum operational work. Before choosing a VM, ask honestly whether a managed service would satisfy the requirement. For new applications written in modern runtimes, App Service or Azure Functions covers the majority of use cases with far less maintenance overhead.

When a VM is the right choice

There are genuine scenarios where VMs are the correct answer:

• Lift-and-shift migrations. You have an existing application running on a physical server or VMware and want to move it to Azure without rewriting it. Replicating the server as an Azure VM is the lowest-risk path.
• Applications with OS-level requirements. Some software requires specific kernel versions, custom kernel modules, or system libraries that managed platforms do not expose. A VM gives you full OS access.
• Windows Server applications. IIS-hosted applications, COM+ components, and software that depends on Windows-specific services are often easier to run on Windows Server VMs than to containerise.
• Self-managed database servers. When a managed database service does not support your required version, extension, or configuration, running PostgreSQL, MySQL, or SQL Server on a VM gives you full control — at the cost of managing backups, replication, and patching yourself.
• CI/CD build agents. Self-hosted build agents for Azure Pipelines or GitHub Actions often run as VMs when custom build toolchains or hardware acceleration (like GPU builds) are needed.

Key concepts you will encounter immediately

VM sizes

Azure organises VM sizes into families named by workload type: B-series for burstable workloads, D-series for general purpose, E-series for memory-intensive applications, F-series for compute-heavy jobs, and so on. The naming convention encodes the family, generation, and specs. For example, Standard_D4s_v5 is a v5-generation D-series VM with 4 vCPUs and premium storage support. See VM sizes explained for a full breakdown.

Managed Disks

Every VM has at least one OS disk, and you can attach additional data disks. Azure Managed Disks are the standard storage option — volumes fully managed by Azure, backed by Standard HDD, Standard SSD, Premium SSD, or Ultra Disk depending on the performance you need. Disk type has a significant impact on both cost and IOPS. See Azure Managed Disks for how to choose.

Images

An image is the template your VM boots from. Azure Marketplace has hundreds of pre-built images: Ubuntu, Windows Server, Red Hat, SUSE, SQL Server, and many more. You can also create custom images from existing VMs — useful when you need a golden image with your organisation’s software and configuration baked in.

Network Security Groups

A Network Security Group (NSG) is the firewall attached to a VM’s network interface or its subnet. NSG rules define which traffic is allowed or denied by protocol, port, and source address. By default, Azure blocks all inbound traffic to new VMs. You explicitly allow only what you need.

Building for availability

A single VM with no redundancy configuration has a 99.9% Azure SLA for Premium SSD storage. For anything production, that means roughly 9 hours of potential downtime per year from Azure-side issues — and that figure does not include downtime you cause yourself through misconfigured deployments.

Three mechanisms improve availability:

• Availability Zones. Deploy VMs across physically separate data centers within the same region. Protects against a complete data-center failure. Azure guarantees 99.99% uptime for VMs deployed across two or more zones.
• Availability Sets. Distribute VMs across fault domains (different physical racks) and update domains (groups rebooted separately during maintenance). Does not protect against data-center failures, but costs nothing extra and reduces simultaneous downtime from Azure maintenance events.
• Virtual Machine Scale Sets. Run multiple identical VMs behind a load balancer, scaling in or out automatically based on demand. Scale Sets can span Availability Zones and are the standard approach for running horizontally scalable applications on VMs. See Virtual Machine Scale Sets.

How VM billing works

Azure bills VM compute time per second, from the moment the VM starts until it is deallocated. There are two states where costs differ:

• Running. Full compute cost accrues — CPU, RAM, and any software licensing (Windows Server adds an OS cost on top of the compute cost).
• Stopped (not deallocated). You shut down the OS but did not deallocate in Azure. Microsoft still has physical hardware reserved. Compute charges still apply.

To stop paying for compute, you must deallocate the VM — via the portal, az vm deallocate, or an auto-shutdown schedule. When deallocated, you only pay for the managed disk storage attached to the VM.

For cost reduction on stable workloads, Azure Reserved VM Instances offer 40–70% discounts in exchange for a 1-year or 3-year commitment. For fault-tolerant, interruptible workloads, Azure Spot VMs offer discounts up to 90% on unused capacity.