Case Study: Virtualization Behind AWS EC2

How Amazon's virtual servers moved from Xen to the Nitro System, and what happens when you launch an instance.

Amazon EC2, launched in 2006, is a good example of virtualization turned into a product. Every EC2 instance is a virtual machine, and the way AWS runs those VMs has changed significantly over the years.

Phase 1: Xen-Based Virtualization
The early EC2 fleet ran on the open-source Xen hypervisor, a Type 1 hypervisor. Many customers' VMs shared each physical host, and Xen kept them isolated and divided up CPU and memory.
This delivered the core IaaS promise: instead of buying a server, you called an API and received a VM. But there was a cost. In the classic Xen design, a privileged management domain (dom0) handled network and disk I/O for all guests. That software layer used host CPU and memory that customers were paying for, and it added some overhead and variability to I/O performance.
Phase 2: The Nitro System
To reduce that overhead, AWS built the Nitro System. Instead of handling networking, storage, and management in software on the host, Nitro offloads those jobs to dedicated hardware cards and a purpose-built security chip. The hypervisor it uses is a lightweight one based on KVM, and it focuses mainly on allocating CPU and memory.
AWS describes the main results as:
• More resources for customers: **less of the host is spent running virtualization overhead, so more of it goes to your instance.
• **Better and more consistent I/O: networking and EBS storage run on dedicated hardware.
• Stronger isolation and security: the management plane is separated from customer workloads.
• Faster innovation: AWS can offer new instance types more quickly, including bare metal instances that give you the whole physical server with no hypervisor between you and the hardware.
What Happens When You Launch an Instance
Here is the virtualization story in a simplified sequence:

1. You request an instance, for example a t3.micro, through the console, CLI, or API.
2. AWS's control plane authenticates you, checks your limits, and picks a physical host with spare capacity in your chosen availability zone.
3. The hypervisor on that host allocates virtual CPUs and memory to a new VM.
4. The VM boots from your chosen machine image (AMI).
5. A virtual disk (EBS volume) and a virtual network interface are attached, with Nitro hardware handling that traffic.
6. You are billed for the time the instance runs. When you stop or terminate it, the capacity goes back to the pool. You can see virtualization at work from inside an instance. On a Nitro-based Linux instance, you can check the hypervisor and device types: # Show the hypervisor the instance reports cat /sys/devices/virtual/dmi/id/sys_vendor

Show virtualized NVMe and network devices
lsblk
ip link show
The disks and network interface you see are virtual devices, presented to the guest operating system as if they were real hardware.
Lessons from the EC2 Case
• Virtualization is what makes self-service, pay-as-you-go servers possible.
• A hypervisor alone is not the whole story. Moving I/O and management into dedicated hardware improved performance and security.
• Cloud providers keep reworking this layer. As a customer you get the benefits without changing how you launch a server.
• The same API call can produce a shared VM or a bare metal server, depending on the instance type you choose.
For exact current details of Nitro and instance types, check the AWS documentation, since the product evolves.