How the Nitro System Transformed EC2 - From Xen to KVM, Eliminating Virtualization Overhead
Learn about the technical background behind EC2's migration from the Xen hypervisor to the Nitro System, the three-layer architecture of Nitro Cards, Nitro Hypervisor, and Nitro Enclaves, and the design philosophy that achieved bare-metal-level performance.
EC2's First Decade Was the Era of Xen
When EC2 launched in 2006, it adopted the Xen hypervisor as its virtualization technology. Xen was an open-source hypervisor developed at the University of Cambridge and one of the most mature virtualization technologies at the time. In Xen's paravirtualization mode, the guest OS kernel was modified to communicate directly with Xen, achieving higher performance than full virtualization. However, Xen-based EC2 had several structural issues. First, network and storage I/O was processed by the host OS CPU, so the host CPU became a bottleneck under I/O-intensive workloads. Second, the host OS (Dom0) expanded the security attack surface. As a privileged domain, Dom0 could access the memory of all guest VMs, meaning that if Dom0 was compromised, all guest VMs were at risk. Third, hypervisor overhead consumed 10-30% of the physical server's CPU for virtualization management.
Nitro Cards - Offloading I/O to Dedicated Hardware
The core innovation of the Nitro System was offloading network, storage, and security functions that were previously handled by the host CPU to dedicated ASIC (Application-Specific Integrated Circuit) chips. There are three types of Nitro Cards. The Nitro Card for VPC handles network processing (VPC encapsulation, security group filtering, ENA packet processing). The Nitro Card for EBS handles block storage I/O (reads and writes to EBS volumes, encryption and decryption). The Nitro Card for Instance Storage manages local NVMe storage. By completely separating these functions from the host CPU, nearly 100% of the host CPU can now be allocated to guest VMs. While 10-30% of a physical server's CPU was consumed by virtualization management in the Xen era, the Nitro System reduced this to nearly zero. At cloud-infrastructure scale, this difference translates to enormous cost savings. Saving 10% of CPU across millions of servers is equivalent to the cost of hundreds of thousands of servers.
Nitro Hypervisor - The Ultimate in Lightweight Design
The Nitro Hypervisor is an extremely lightweight hypervisor based on KVM (Kernel-based Virtual Machine). While Xen's Dom0 ran a general-purpose Linux kernel, the Nitro Hypervisor is a custom kernel with only the minimum functionality needed for virtualization. The network stack, storage stack, file system, and other functions that traditional hypervisors included have all been offloaded to Nitro Cards, making the hypervisor's codebase extremely small. This lightweight design is also significant from a security perspective. Less code means fewer vulnerabilities and a smaller attack surface. AWS describes the Nitro Hypervisor's security model as having "no mechanism for the hypervisor to access guest VM memory." While Xen's Dom0 could freely access guest VM memory, the Nitro Hypervisor simply does not have that capability. This makes it technically impossible for even AWS employees to access guest VM data.
Bare Metal Instances - EC2 Without Virtualization
A byproduct of the Nitro System was the creation of EC2 bare metal instances (e.g., m5.metal). Since Nitro Cards handle network and storage processing, EC2 management functions (start/stop, monitoring, security groups) can be maintained even with the hypervisor completely removed. On bare metal instances, the physical server's CPU and memory are provided directly to the guest, and virtualization overhead is literally zero. While use cases for bare metal instances are limited, there are important scenarios. First, licensing constraints. Some Oracle Database and Windows Server licenses are charged based on physical core count, making it difficult to identify physical cores in virtualized environments. Bare metal instances provide clear physical core counts. Second, nested virtualization. Running VMware ESXi or KVM as a guest OS requires bare metal instances. AWS Elastic VMware Service (EVS) runs VMware vSphere on bare metal instances. Third, performance-critical workloads. In HPC (High Performance Computing) and financial real-time trading, even the slightest virtualization overhead may be unacceptable.
Nitro Enclaves - Hardware-Level Confidential Computing
Nitro Enclaves is a confidential computing environment that leverages the isolation capabilities of the Nitro System. An Enclave is an isolated virtual machine with CPU and memory separated from the parent instance, with no persistent storage, network access, or external interactive access whatsoever. Communication with the parent instance is limited to vsock (virtual socket), a local communication channel. This extreme isolation ensures that data processed within the Enclave cannot be accessed by the parent instance's OS, the hypervisor, or AWS employees. Enclave integrity can be verified through cryptographic attestation. When an Enclave starts, the Nitro System generates a signed certificate containing hash values of the Enclave's code and data. External services (such as KMS) can verify this certificate before providing data to the Enclave. Use cases include PII processing (PII tokenization), cryptographic key management, and multi-party computation (where multiple organizations compute jointly without sharing data). To systematically learn about AWS virtualization technology and security design, specialized books (Amazon) are a helpful resource.