Azure Virtual Machines
In plain English
Plain definition
Azure Virtual Machines is Microsoft Azure's Infrastructure-as-a-Service offering for running Windows or Linux compute instances on demand, with defined boundaries for sizing, storage, networking and shared operational responsibility.
Technical Definition
An Azure Virtual Machine (VM) is a software-defined compute instance hosted on Microsoft’s Hyper-V-based virtualisation fabric within an Azure datacentre region. Each VM is created from a VM size (also called a “series”) that fixes its virtual CPU count, memory allocation, temporary storage and expected network throughput. A VM boots from an operating system image or a custom disk image, attaches one or more managed disks for persistent storage, and is connected to a virtual network (VNet) subnet through a network interface. Lifecycle operations – create, resize, stop, start, deallocate and delete – are managed through Azure Resource Manager (ARM), either directly or through infrastructure-as-code tooling that calls the ARM API.
Operational Relevance
Azure Virtual Machines matters operationally because it is the layer at which an organisation takes on responsibility for the guest operating system, its patching, its configuration and the workloads running inside it, while Azure remains responsible for the underlying host, hypervisor and physical infrastructure. This shared-responsibility boundary determines who must act when something goes wrong: guest OS failures, misconfigured firewall rules and unpatched software are the operator’s concern; host hardware failure and hypervisor-level faults are Azure’s concern. Sizing decisions affect cost and headroom directly, and resizing or deallocating a VM changes compute billing even though attached disks continue to accrue storage cost while the VM is deallocated.
Architecture Relationship
A single Azure Virtual Machine rarely stands alone in a production architecture. It sits inside a virtual network for connectivity, behind or alongside a network security group for traffic filtering, and is commonly grouped with other VMs into an availability set or spread across availability zones so that a single hardware or datacentre fault does not remove an entire service. Managed disks provide the persistent storage layer, and load balancers or application gateways are typically placed in front of a VM scale set or a pool of individual VMs to distribute traffic. Identity and access to the VM itself, and to resources it calls, are usually governed through Azure role-based access control (RBAC) and, where supported, managed identities rather than embedded credentials.
Example
A platform team needs a bounded, non-production validation environment for a new application tier. They provision a single Azure Virtual Machine of a general-purpose size in an isolated resource group and virtual network, attach a managed OS disk and a separate data disk, and apply a network security group that permits only the specific inbound ports required for testing. Once validation of the application build is complete, the VM is deallocated (stopping compute billing while retaining its disks) rather than deleted, so the environment can be restarted for the next validation cycle without rebuilding it from scratch.
Misunderstanding
A common misunderstanding is treating “stopped” and “deallocated” as the same state. Stopping a VM from within the guest operating system (for example, shutting down Windows or Linux) leaves the VM allocated to Azure compute capacity and still billed for compute, even though nothing is running inside it. Only an explicit deallocation through the Azure control plane releases the compute allocation and stops compute billing; attached disks and any static configuration continue to be billed as storage regardless of VM power state. Confusing the two states leads to unexpected cost and to false assumptions about whether a dynamic public IP address will be retained after a restart.
Related Terms
- Virtual Network (VNet)
- Managed Disk
- Availability Set
- Availability Zone
- Azure Resource Manager (ARM)
- Virtual Machine Scale Set
Further Reading
Readers verifying current VM size series, SLA terms, pricing tiers or feature availability should confirm those specifics directly against Microsoft’s current Azure Virtual Machines documentation, since size series, pricing and SLA figures change over time and were not confirmed against a primary Microsoft source for this entry. The material above describes stable architectural concepts that have remained consistent across recent Azure platform revisions, and any change to the described behaviour should be validated in an isolated subscription before being relied upon operationally.