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 representative virtualization technologies of its 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 guest VM memory, so if Dom0 was compromised, guest VMs were at risk. Third, due to hypervisor overhead, part of the physical server's CPU was used 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. Nitro Cards come in different types by purpose, including the following. 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 separating these functions from the host CPU, more of the host CPU's resources can now be allocated to guest VMs. Compared with the Xen era, the CPU used for virtualization management decreased with the Nitro System. At cloud-infrastructure scale, this difference affects costs. The more servers there are, the more CPU savings add up in terms of cost.
Nitro Hypervisor - The Ultimate in Lightweight Design
The Nitro Hypervisor is a 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 been offloaded to Nitro Cards, so the hypervisor itself has a limited role. This lightweight design also matters from a security perspective. Less code means fewer vulnerabilities and a smaller attack surface. AWS explains that the Nitro System has no mechanism to log in to EC2 hosts or access instance memory. Xen's Dom0 was a privileged domain that could access guest VM memory. This restriction is built into the Nitro System itself, and AWS operators cannot bypass it either.
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) are maintained even in configurations without a hypervisor. On bare metal instances, the physical server's CPU and memory are provided directly to the guest, with no virtualization overhead. 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. Communication with the parent instance is limited to vsock (virtual socket), a local communication channel. This isolation means that data and applications within the Enclave cannot be accessed by processes or users of the parent instance (including root and administrators). 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).
References (Official AWS Resources)
The primary sources for this page are the official AWS website and documentation. Check the official pages below for the latest specifications and pricing.
If this page and the official documentation disagree, treat the official documentation as authoritative.