Skip to main content

Virtual machines

A (VM) is an isolated guest operating system environment running atop a physical server via a hypervisor. From the perspective of the software running inside it, a VM behaves like dedicated bare-metal hardware: it has virtual CPU cores, allocated memory, network interfaces, and storage controllers. As the foundational primitive of modern cloud computing, virtual machines underpin virtually every higher-level service that providers offer, from managed Kubernetes worker nodes to relational database engines.

While launching an instance takes only seconds through an API call or console click, operating virtual machines at scale requires substantial operational discipline. Unlike managed serverless platforms, raw virtual machines place the burden of guest operating system updates, kernel security patches, host configuration, monitoring agents, and backup verification squarely on your engineering team. Furthermore, standard compute billing runs continuously on a per-second or per-minute basis, accumulating costs regardless of whether an instance is processing critical workloads or sitting idle.

Sizes

Cloud providers organize virtual machines into specialized instance families designed around varying hardware ratios. General-purpose instances maintain an even balance of compute cores to memory, making them the standard starting point for web applications, build runners, and microservices. Compute-optimized instances allocate a higher ratio of CPU to memory for computationally intensive workloads like video transcoding, scientific modeling, or high-traffic API gateways. Memory-optimized instances feature massive RAM allocations relative to CPU cores, tailored for in-memory caches, search indexes, and large relational databases.

Instance naming schemes encode the family, generation, and target architecture. For example, newer generations incorporate modern processor architectures—such as custom ARM-based chips alongside updated x86 silicon—delivering improved price-to-performance over older hardware. Leaving long-running workloads on legacy instance types without periodic architectural reviews is an easy way to overpay for compute.

What is attached

In cloud architecture, a virtual machine primarily represents ephemeral compute and memory capacity. Durable persistence is provided through modular attached components:

  • Persistent storage: The primary boot disk and secondary data partitions are provided by , a network-attached virtual volume that appears to the operating system as a standard block device. Because block volumes exist independently of the underlying hypervisor hardware, they persist across instance stops, reboots, and hardware migrations.
  • Ephemeral local storage: Many instance types also offer direct-attached physical NVMe drives, known as ephemeral or instance store disks. While these drives deliver exceptional read/write throughput and sub-millisecond latency, their contents are lost whenever the virtual machine stops or experiences a hardware retirement event. They serve as scratch space, compilation caches, or buffer pools rather than persistent data stores.
  • Network interfaces: Virtual network adapters link the instance to your virtual network, assigning private IP addresses and, when explicitly required, routable public addresses for internet exposure.
  • Workload identity: Attaching a dedicated IAM identity directly to the instance allows software running on the machine to acquire short-lived authentication tokens from the local instance metadata service, eliminating the need to bake long-lived API secrets into application configuration files.

Images

Virtual machines instantiate from a base —a point-in-time snapshot of an operating system filesystem pre-configured with bootloaders, system packages, and essential utilities. While providers supply base distributions of Linux and Windows Server, mature operations teams typically build customized machine images using automated build pipelines.

Baking dependencies, monitoring agents, and application binaries directly into immutable golden images fundamentally changes server management. Rather than connecting to running servers over SSH to apply configuration changes or update packages in place, teams replace entire instances with fresh machines launched from updated images. This immutable infrastructure pattern prevents configuration drift and guarantees that development, staging, and production environments execute identical software stacks.

Scaling

Every virtual machine has fixed hardware limits. When resource utilization approaches physical saturation, there are two scaling paths:

  1. Vertical scaling (scale up): Upgrading the instance to a larger tier with more cores and memory. While simple and requiring no application architecture changes, vertical scaling involves downtime during instance resizing and eventually collides with hardware and budget ceilings.
  2. Horizontal scaling (scale out): Distributing inbound traffic across a fleet of interchangeable virtual machines behind a managed .

Horizontal elasticity requires that application instances remain stateless: user session state, uploaded media files, and transaction histories must be offloaded to external caches, databases, and object stores. Cloud providers manage fleet expansion and contraction using an . By evaluating target utilization metrics (such as average CPU utilization or request queue depth), the autoscaling group launches new instances during traffic surges and drains underutilized capacity during quiet periods. Crucially, the group also performs continuous health checks, automatically terminating degraded instances and provisioning healthy replacements to maintain target capacity.

Before you add a machine to an autoscaling group

Ensure new instances initialize autonomously without manual intervention.

  1. Bake application dependencies and configuration into the machine image so instances boot directly into a running state.
  2. Externalize all user session state, cached data, and uploaded assets to shared storage or managed data services.
  3. Assign a cloud service identity to the instance template rather than storing static API credentials on the filesystem.
  4. Configure deep application health checks that verify internal database connectivity and service readiness, rather than simple TCP ping responses.

What it costs

Virtual machines bill continuously while in an active running state. When an instance is stopped, compute charges pause, but attached persistent block storage volumes and static public IP reservations continue to accrue hourly fees. A major source of unnecessary cloud expenditure is abandoned development or test instances that were spun up for temporary tasks and never terminated.

Production deployments typically combine three distinct purchasing models to optimize cost:

  • On-demand capacity: Pay-as-you-go pricing with no upfront commitment, offering maximum flexibility for unpredictable or experimental workloads.
  • Committed use and reservations: Significant discounts (often 30% to 70%) granted in exchange for committing to a consistent baseline of compute usage over a one-year or three-year horizon.
  • : Idle physical server capacity sold by the provider at deep discounts (frequently up to 90%), with the caveat that the provider can reclaim the hardware on short notice (typically a 30-second to two-minute warning). Spot instances are exceptionally well-suited for resilient, fault-tolerant workloads—such as batch processing pipelines, stateless worker fleets, and containerized build systems—but are unsuitable for stateful databases or single-instance applications.

When a machine is the right answer

Deploying directly to virtual machines remains the right architectural choice when software requires access to custom OS kernels, specific device drivers, legacy enterprise dependencies, or commercial software licenses tied to virtual hardware signatures. VMs are also ideal when an engineering team requires granular control over local network interfaces, storage volume striping, or low-level hypervisor parameters.

However, for standard web applications, microservices, and background tasks, managing individual virtual machines introduces unnecessary operational overhead. Container orchestrators and serverless platforms abstract away operating system maintenance, node provisioning, and hardware lifecycle, letting teams focus on delivering application functionality.

Terms introduced

  • Virtual machine: a slice of a physical server, sold as a whole computer with its own operating system.
  • Block storage: a network-attached volume that behaves as a local disk and outlives the machine.
  • Image: a disk snapshot with an operating system and software installed, used to start new machines.
  • Load balancer: a service that spreads incoming requests across a set of interchangeable machines.
  • Autoscaling group: a managed set of identical machines that grows, shrinks, and self-heals against a target.
  • Spot capacity: spare provider hardware sold at a discount on the condition that it can be reclaimed.

How providers do it

Virtual machine offerings across AWS, Azure, and Google Cloud share nearly identical core capabilities, differing primarily in terminology, instance naming conventions, and compute lifecycle mechanics.

ConceptAWSAzureGoogle Cloud
Virtual machineAmazon EC2 instanceAzure Virtual MachineCompute Engine VM instance
Sizing and familiesInstance type (e.g. m7g.large)VM size (e.g. Standard_D4s_v5)Machine type (e.g. e2-standard-4)
Machine imageAmazon Machine Image (AMI)Azure Compute Gallery or Marketplace imageCustom or public disk image
Persistent block storageElastic Block Store (EBS) volumeAzure Managed DiskPersistent Disk, Hyperdisk
Ephemeral local diskInstance store volumeTemporary resource diskLocal SSD
Load balancingApplication Load Balancer, Network Load BalancerApplication Gateway, Azure Load BalancerCloud Load Balancing
Autoscaling fleetEC2 Auto Scaling groupVirtual Machine Scale Set (VMSS)Managed instance group (MIG)
Machine workload identityIAM role, via EC2 instance profileManaged identityAttached service account
Committed pricingReserved Instances, Savings PlansReserved VM Instances, savings plansCommitted use discounts (CUDs)
Spare spot capacitySpot InstancesSpot Virtual MachinesSpot VMs
Compute billing cessationStop the instanceDeallocate the VM (guest OS shutdown continues billing)Stop the VM

Every product name and technical mapping above is confirmed against provider documentation. Specific parameters regarding spot interruption grace periods and sustained-use discounts are marked unconfirmed in the provider tabs below.

A critical operational difference lies in stop versus deallocation semantics:

  • On AWS and Google Cloud, stopping a virtual machine halts compute charges immediately, leaving only attached persistent disk storage to accrue fees.
  • On Azure, issuing a shutdown command from within the guest operating system leaves the VM in a Stopped (allocated) state that continues to incur full compute charges. To completely cease compute billing on Azure, the machine must be placed into the Deallocated state via the Azure portal, CLI, or control plane API. Automation scripts designed to pause non-production environments overnight must account for this distinction to realize actual cost savings.

What this maps to: Amazon EC2 (Elastic Compute Cloud). Every other AWS compute product runs on EC2 underneath.

ConceptOn AWSStatus
Virtual machineAn EC2 instanceconfirmed
Size and familyAn instance type, e.g. m7g.large: family letter, generation number, size. m general purpose, c compute optimised, r memory optimised, t burstable. A g suffix means Graviton (ARM)confirmed
ImageAn AMI (Amazon Machine Image). Build your own with EC2 Image Builder or Packerconfirmed
Block storageEBS (Elastic Block Store) volumes. Volume types trade cost against IOPS; gp3 is the general-purpose defaultconfirmed
Local diskInstance store, on the instance types that have one. Lost on stopconfirmed
Load balancerElastic Load Balancing: Application Load Balancer (HTTP, layer 7) and Network Load Balancer (TCP, layer 4)confirmed
Autoscaling groupEC2 Auto Scaling group, with a launch template naming the AMI and instance typeconfirmed
Identity on the machineAn IAM role attached through an instance profile. Credentials come from the instance metadata service; use IMDSv2confirmed
Committed pricingReserved Instances and Savings Plans, for one or three yearsconfirmed
Spot capacitySpot Instances. AWS gives a two-minute interruption notice before reclaiming oneunconfirmed; check current docs

Their vocabulary

Standard termTheir term
Virtual machineInstance
SizeInstance type
ImageAMI
Stop billingStop the instance; EBS still bills. Terminate to stop both

Where to look

The EC2 console lists instances, AMIs, and Auto Scaling groups per region. If you want to find long-running instances that nobody has looked at in a while, filter Cost Explorer to EC2.

Last verified: never.


Check your understanding

0 of 4 answered

  1. You stop a virtual machine but do not delete it. What keeps billing?
  2. What is the difference between a block storage volume and a machine's local disk?
  3. Which workload suits spot capacity?
  4. An autoscaling group replaces a machine, and the new one serves errors until someone logs in and copies a config file. What was missing?