What is virtualization? The technology cloud is built on

The plain idea

Take one physical server — its CPU, memory, storage and network interfaces — and imagine slicing it into several smaller, walled-off computers, each with its own operating system, each unaware the others exist. That is virtualization. Every one of those slices, called a virtual machine, behaves exactly like a standalone computer from the inside: you install software on it, reboot it, and secure it as if it were the only thing running on the hardware.

The physical machine underneath is called the host; each virtual machine it runs is a guest. A software layer sits between the two, dividing up the host’s real CPU cycles, memory pages and disk blocks among the guests and making sure none of them can see or touch what belongs to another. That layer is what does the actual virtualising, and it has its own name — the hypervisor, covered in a dedicated explainer.

Why it matters

Two benefits follow directly from splitting one machine into many. The first is efficient use of hardware: instead of buying a dedicated server for every workload and watching most of its capacity go unused, you run several workloads on the same physical box, each sized to what it actually needs. The second is isolation: a crash, misconfiguration or compromise inside one virtual machine does not reach across into another, even though they share the same underlying metal.

Those two properties together are what make renting compute possible at all. A cloud provider does not hand you a physical server — it hands you a virtual machine carved from a much larger physical fleet, alongside virtual machines belonging to other customers you will never see or affect. Containers solve a related problem in a different way, with lighter isolation drawn at the operating-system level rather than the hardware level; the comparison between the two approaches is covered in the containers-versus-virtual-machines explainer rather than repeated here.

The main types, briefly

Server (or compute) virtualization — splitting one physical server into multiple virtual machines — is the type most people mean by the word, and the one this article focuses on. But the same abstraction idea extends to other parts of the data centre.

• Storage virtualization — pooling physical disks from multiple devices into a single logical store, so capacity can be allocated and resized without caring which physical drive the bytes actually sit on.
• Network virtualization — creating logical networks, switches and routers in software, independent of the physical cabling and network hardware beneath them — the idea a virtual private cloud builds directly on top of.

How it enables cloud computing

A cloud provider’s data centres are, physically, enormous fleets of servers. Virtualization is what turns that fixed physical estate into something you can rent in small, flexible slices: launch a virtual machine sized to your workload, run it for an hour or a year, then release it, and the provider reassigns that capacity to someone else. None of that elasticity — the defining promise of cloud computing — is possible if compute can only be allocated one whole physical server at a time.

It is also what underpins multi-tenancy: many customers’ workloads running on shared physical infrastructure while remaining invisible to each other, secured by the same isolation guarantee that separates one guest virtual machine from another on a single host.

How it relates to containers

Virtual machines and containers both give you isolated environments to run software in, but they draw the isolation boundary at different layers. A virtual machine virtualises the hardware, so each one carries its own full guest operating system; a container virtualises at the operating-system level, sharing the host’s kernel while keeping each container’s processes and filesystem separate. That makes containers markedly lighter and faster to start, at the cost of a thinner isolation boundary — the trade-off explored fully in the containers-versus-virtual-machines and what-is-docker articles, which this piece deliberately leaves to them.

In practice, cloud architectures often use both: virtual machines as the foundation a provider’s infrastructure — and often your own compute instances — run on, with containers deployed on top of those virtual machines for the applications themselves.

Where virtualization shows up in certification study

Virtualization itself is rarely tested by name once you are past the foundational level, but it is the concept every compute service quietly assumes. Foundational exams such as AWS Cloud Practitioner and Microsoft’s Azure Fundamentals expect you to understand that cloud compute instances are virtual machines running on shared physical hardware, and why that matters for cost, elasticity and isolation. From there, associate-level tracks build on the idea without restating it — compute-instance types, auto scaling and multi-tenant security all assume you already grasp that a "server" in the cloud is a virtual slice of a much larger physical one.