The question this answers
What am I actually getting when I rent a machine that is not a machine, and what do I owe in return?
A team must run a workload that expects a real operating system — a pinned kernel version, a licensed daemon that binds to a device, long-lived processes, a local scratch disk large enough for a working set — and it must run next to other companies' workloads without any of them being able to read its memory.
A full operating system the team controls from the kernel upward, on virtual hardware that can be resized, snapshotted, cloned and rebuilt in minutes, separated from every other tenant by a boundary the CPU enforces rather than one implemented in software you would have to trust.
What the provider hands you, layer by layer
A virtual machine is not a smaller computer. It is a set of virtual devices — a CPU that is really a scheduled share of physical cores, memory that is really a mapped region of the host's RAM, disks that are really network-attached volumes or slices of local NVMe, and a network interface that is really a software port on a virtual switch. The guest operating system boots against those devices believing they are hardware, because from inside the guest there is no reliable way to tell that they are not.
That belief is the whole product. It means every operating system, every init system, every daemon and every driver that expected real hardware keeps working unmodified. It is why the virtual machine remains the compatibility answer of last resort: when a workload will not fit into a container image, a function, or a managed platform, it will fit into a VM, because a VM is just a computer.
How the illusion is built — how guest page tables are nested or shadowed, what happens when a privileged instruction traps into the hypervisor, why a paravirtualized device driver is faster than an emulated one — is operating-systems material and is taught properly in that domain: see Why Virtual Memory? and VM vs Container: Where the Boundary Is. This lesson deliberately does not re-teach it. It answers the three questions that domain does not: what you get, what you owe, and what it costs.
Isolation is the defining property
Density is not what makes a virtual machine interesting; containers are denser. Start time is not it either; containers start in a fiftieth of the time. What a VM has that nothing lighter has is a boundary that does not depend on the correctness of a shared kernel. Two guests on one host each run their own kernel, and a syscall made in one of them is serviced by that guest's kernel, never by the neighbour's. The surface between tenants is the hypervisor interface, which is small, heavily audited, and enforced with hardware virtualization extensions.
That difference has a practical consequence you can act on. If your workload executes code you did not write — customer-supplied build steps, notebook cells, plugin code, LLM tool calls that shell out — the shared-kernel boundary is carrying more weight than it was designed for, and a kernel bug becomes a cross-tenant bug. A VM or microVM per unit of untrusted work is the ordinary answer, and it is why the providers themselves build their function platforms on microVMs rather than plain containers.
It is also worth being precise about what the boundary does *not* cover, because that is where real incidents come from. Isolation is per-guest memory and per-guest kernel. It is not isolation of the network — two VMs in the same subnet with a permissive security group can talk freely. It is not isolation of identity — a VM that carries an over-broad instance role can reach everything that role can reach, and the hypervisor has no opinion about it. And it is not isolation of physics: the cores, the memory bandwidth and the disk queue are shared, which is the subject of Hypervisors and Shared Hosts.
- Separate kernels are the point. A container shares the host kernel; a VM does not — see Containers vs Virtual Machines.
- Untrusted or tenant-supplied code is the case where the difference stops being academic.
- The boundary isolates memory and kernel. It does not isolate your network, your identity, or the physical resources being shared.
- Live migration means the provider can move a running guest between hosts; it usually hides host maintenance and occasionally shows up as a latency blip you did not cause.
What you owe, and where it lands on the bill
The moment you take a guest operating system, you take its maintenance. Kernel and package patching, a reboot policy, log rotation before the root filesystem fills, time synchronisation, host firewall rules, a supervisor that restarts the process, an agent for metrics and one for logs, and an answer to "how do we get a shell on this and who is allowed to". None of that is billed by the provider, and all of it is real work that shows up as headcount rather than as a line item — which is precisely why it is systematically underestimated when a VM fleet is chosen over a managed platform.
The billed cost has a shape worth learning. Compute is charged for existence, not for usefulness: an instance idling at 3% is billed identically to one at 90%, which makes Idle Capacity: Headroom or Waste? and Right-Sizing Without Causing an Outage the two largest levers you have. Attached storage bills whether or not the instance is running, so a stopped VM is cheaper but not free. And the things that outlive the instance — orphaned volumes, unattached addresses, forgotten snapshots — accumulate for years because nothing ever fails to remind you about them.
One number dominates all of it and is rarely written down: the commitment discount. Reserving or committing capacity for a term is typically a large reduction against on-demand rates, and interruptible capacity is a larger one again. Both are workload decisions rather than procurement decisions — a steady baseline earns a commitment, and resumable batch work earns interruptible capacity — and getting them wrong in either direction is expensive.
Bars are relative weights, not currency. Real rates depend on provider, region, commitment and volume.
Key points
- A VM is virtual hardware plus a guest OS: the compatibility answer of last resort, because it is just a computer.
- Isolation, not density or speed, is what a VM has that a container does not — separate kernels, a hypervisor boundary enforced by the CPU.
- The boundary covers memory and kernel. It does not cover your network rules, your instance identity, or contention for shared physical resources.
- Taking the guest OS means taking patching, reboots, log rotation, agents, supervision and shell access policy — unbilled and routinely underestimated.
- Compute bills for existence rather than usefulness, so idle capacity and orphaned attachments are the two cost failures that recur everywhere.
- Virtualization internals belong to the Operating Systems domain; this module covers what you get, what you owe and what it costs.
The loop, answered
Every field is required, which is why no lesson here can recommend something without saying what it costs and what simpler thing to consider first.
- • A control plane request selects an instance size, an image, a zone, a network placement and an identity, and the provider allocates a slot on a physical host with capacity.
- • The hypervisor creates virtual devices for the guest — vCPUs backed by scheduled time on physical cores, a memory map, block devices, and a virtual NIC attached to a software switch in your virtual network.
- • The guest kernel boots from the image against those devices exactly as it would against hardware, running its own init system and drivers.
- • Startup configuration runs inside the guest — user data or a cloud-init equivalent — fetching secrets, assuming the instance identity and starting services.
- • The instance identity is exposed to the guest through a metadata service, which is how a workload obtains short-lived credentials without a static key — see Roles vs Static Keys.
- • Resizing means stopping the guest and re-launching it against a different virtual hardware profile; the guest OS sees a reboot, not a hot upgrade.
- • Kernel and package patching, plus a reboot policy — including who is allowed to reboot a production instance and when.
- • Image building, so that a replacement instance is genuinely the same machine as the one it replaces.
- • A supervisor or unit file that restarts the process after a crash and starts it after a reboot; nothing does this for you.
- • Log shipping and metric collection agents, and disk-space management so log growth never fills the root filesystem.
- • Host-level access: SSH key or session-manager policy, audit of who connected, and a stated position on whether shell access to production is normal.
- • Backups of anything on local disk, because local disk dies with the instance.
- • The host fails and the instance disappears without a signal — no shutdown hook runs, no in-flight request completes, and anything on local disk is gone.
- • The root filesystem fills with logs; the process stays up but cannot write, health checks that only touch memory stay green, and the failure presents as scattered 500s.
- • A kernel patch is applied and the machine does not come back, because a service that was started by hand months ago was never enabled at boot.
- • The instance was resized months ago but the application config still assumes the old memory, so the OOM killer takes the process at peak instead of at deploy time.
- • Neighbour contention on the physical host raises tail latency while guest CPU utilisation stays flat, so every autoscaling signal you have says nothing is wrong.
- • A permissive instance role turns a single application vulnerability into access to every bucket and secret the role could reach — the isolation boundary does not apply to identity.
- • Vertical scaling has a hard ceiling at the largest instance size in the family, and reaching it requires a stop and start — a planned outage for that machine.
- • Horizontal scaling works but is slow: boot plus configure plus warm-up is tens of seconds to minutes, which is the number that decides whether autoscaling can answer your bursts at all.
- • Memory usually runs out before CPU for application servers, and disk throughput before either for anything that writes — check which one you actually exhausted before resizing.
- • Fleet-wide replacement multiplies startup effects: two hundred instances initializing at once means two hundred connection pools opening at once.
- • The hypervisor boundary is the strongest routine isolation available and is the reason VMs and microVMs are used for untrusted code — see Containers vs Virtual Machines.
- • It isolates nothing at the network layer: reachability between instances is decided entirely by subnet placement and security-group rules.
- • The instance identity is the real blast radius. A workload with a broad role is as dangerous on a perfectly isolated VM as anywhere else — see Least Privilege in Infrastructure.
- • The metadata service is a credential endpoint reachable from inside the guest, so any request-forgery flaw in the application is a credential-theft flaw; require the hardened, token-based access mode.
- • Long-lived instances accumulate unpatched packages, stale keys and manual changes. Instance lifetime is effectively secret lifetime, so short-lived instances are a security property.
- • Encrypt attached volumes and snapshots; underlying physical storage is reclaimed and reused rather than erased on your behalf.
- • Instances bill for existence, not utilisation, so a fleet at 15% average CPU is paying roughly six times what the work requires.
- • Attached storage, addresses and snapshots bill independently of the instance and outlive it, which is how orphaned spend accumulates.
- • Commitment discounts reward a steady baseline and interruptible capacity rewards resumable work; both are workload decisions, and both are large.
- • Operating the guest OS is a real cost that never appears on the invoice, and it is the honest counterweight to "a VM is cheaper than the managed service".
- • Guest CPU, memory, disk usage and disk queue depth — collected by an agent you installed, because the provider sees the virtual hardware and not what the guest is doing with it.
- • Free space on every filesystem, with an alert well before full. A full root filesystem is the single most common avoidable VM outage.
- • Steal time or its equivalent, which is the only guest-visible evidence of contention on the shared host.
- • Patch level and image version per instance, so drift is measurable rather than discovered during an incident.
- • The signal that lies: provider-side instance status checks. They report that the virtual machine is running, which is true right up to and including the moment your process has been dead for an hour.
- • A managed container service, if the workload is an ordinary long-running process in an image. It removes the guest OS, the patching, the agents and the supervisor, and is the right answer more often than VMs are chosen.
- • A managed application platform, if the workload is a plain web service. It removes the entire decision, and for a small team it buys back more time than any optimisation of a VM fleet ever will.
- • A managed database, queue or cache instead of installing one on a VM — running stateful software on an instance you own is where VM operational cost concentrates. See Managed vs Self-Hosted.
- • A single VM under a supervisor with a maintenance window, for a small internal service. No images, no scaling group, no orchestrator; an honest simple answer that many teams talk themselves out of.
- • Bare metal, when virtualization overhead or neighbour contention is genuinely the constraint — high-throughput packet processing, licensed software billed per physical core, or workloads that need real hardware access.
- • A VM buys compatibility with everything and a strong isolation boundary, and charges you an operating system to run for as long as the instance exists.
- • It buys full control over the environment, and charges slow starts that limit how quickly capacity can follow demand.
- • It buys the ability to run anything, which is also the ability to accumulate anything — the reason drift is a VM problem far more than a container problem.
- • Larger instances buy simplicity and charge a bigger failure domain and a harder ceiling — the subject of One Big VM or Several Small Ones.
What people believe, and what is true
A virtual machine is slower than a physical one in ways that matter.
For ordinary CPU and memory work, hardware-assisted virtualization overhead is small. What actually bites is contention with neighbours and virtualized I/O paths — not the abstraction itself.
The provider patches my instance.
The provider patches the hypervisor and the physical host. Everything from the guest kernel upward is yours, and the boundary is exactly where the shared-responsibility model puts it — see Shared Responsibility.
A stopped instance costs nothing.
Compute charges stop; attached volumes, reserved addresses and snapshots keep billing. A stopped fleet is cheaper, not free.
VMs are legacy and containers replaced them.
Containers run on VMs almost everywhere, including inside every managed Kubernetes node group. The question is which boundary you need and who operates the guest OS, not which technology is newer.
Go deeper
Overview
A VM is virtual hardware plus a guest operating system, isolated from other tenants by a hypervisor. You get a complete, compatible computer; you owe everything from the guest kernel upward.
Practical
Decide deliberately: does this workload need a guest OS, or did it just default to one? If it needs one, budget the patching, the image pipeline, the agents and the supervisor as real work, and size the instance from measured utilisation rather than from the old machine.
Advanced
Treat instance lifetime as a security and drift control, not just a cost one. Short-lived instances rebuilt from images have shorter-lived credentials, less accumulated manual change and a genuinely tested replacement path. Then check what the isolation boundary does not cover: subnet reachability, instance role scope and metadata-service exposure.
Internals
The guest believes it owns hardware because privileged instructions trap to the hypervisor and memory translation is nested — a guest-virtual to guest-physical mapping the guest kernel controls, and a guest-physical to host-physical mapping it cannot see. Device access is usually paravirtualized: the guest driver writes to a ring buffer the host consumes, avoiding full device emulation. The Operating Systems domain teaches this properly; here it matters only because it explains why I/O paths, not CPU, are where virtualization overhead concentrates.