Industry observers speculated for years that AWS had developed its own hypervisor, but it wasn't until last November...
that the cloud provider began to disclose details of a system it built to underpin many of its newer instances.
The Nitro system, as AWS dubbed the internal project, starts with a new hypervisor but relies on several other components to offload almost all networking, storage and management overhead. This enables the host CPU to be dedicated to customer instances or workloads and purportedly provides performance that is indistinguishable from bare metal.
Overall, the AWS Nitro system offers great performance benefits for users, as well as the opportunity to use bare-metal instances for particular workloads, such as databases or self-managed container clusters. It's not yet widely available across the EC2 portfolio, but users with compute and I/O-intensive workloads should test Nitro-based instances before they add more EC2 capacity to their current deployment.
The AWS Nitro system: A need for speed
AWS first disclosed details about Nitro at its 2017 re:Invent user conference, where Anthony Liguori, chief engineer for EC2, said Nitro is based on the Linux KVM technology but "does not include general-purpose operating system components."
The impetus for Nitro was hypervisor bottlenecks and shortcomings that started to crop up in 2012, particularly in how hypervisors handled network and storage devices. Because of those issues, AWS said it sought a way to improve a software-only hypervisor architecture, especially around device models, as well as a way to decompose the hypervisor to boost performance and flexibility.
The result was the AWS Nitro system, which consists of a lightweight hypervisor to replace Xen and its device handling system; a custom interface card to handle storage, networking, management, monitoring and security for each Nitro instance; and a security chip integrated onto the motherboard.
Now, Nitro provides the C5 compute-intensive instances, which can scale up to 72 virtual CPUs and 144 GB, with CPU and memory isolation. Virtual Private Cloud (VPC) networking and Elastic Block Store (EBS) storage rely on dedicated hardware used in current-generation EC2 instances.
AWS is tight-lipped about its internal machinations, but Nitro surely used the custom interface application-specific integrated circuit that was designed by AWS' Annapurna group -- at least initially. Those hardware specs, which included two 25 Gigabit Ethernet network interfaces, were discussed at a 2016 re:Invent presentation, but last year, AWS said it was working on a successor.
The cloud provider has probably already deployed a more recent Nitro card, which likely includes other elements revealed in Liguori's talk, including the use of single-root I/O virtualization hardware for network and storage I/O, enhanced networking features and EBS volume I/O, along with hardware support for posted interrupts and Intel Advanced Programmable Interrupt Controller virtualization to improve VM performance.
Implications on instances and users
Eventually, all new instance types will use the AWS Nitro system, but for now, existing instances and some new types will continue to use Xen. The system is the foundation for AWS' bare-metal and compute-intensive instances but also enables several other valuable features, including:
- faster updates to the EC2 instance portfolio, including new sizes and support for refreshed hardware CPUs;
- local nonvolatile memory express (NVMe) storage that provides high-performance, solid-state memory over a local Peripheral Component Interconnect Express interface with inline data encryption;
- hardware acceleration of AWS-enhanced networking features and VPC network interfaces;
- hardware acceleration of EBS processing, including crypto-operations; and
- system-level security hardware to protect against firmware attacks and verify firmware on system boot.
Nitro-based instances will work with most EC2 applications and Amazon Machine Images that use Elastic Network Adapter. Still, even though Nitro doesn't change the EC2 APIs, IT teams may need to modify some applications that rely on undocumented behavior to detect when they are running within EC2.
Also, administrators will notice some differences from applications that run on Xen. Nitro boots from EBS volumes on an NVMe interface, while Xen boots from an emulated integrated development environment device before it switches to the Xen paravirtualized (PV) block device. As a result, Linux instances will not interact with EBS volumes in the same way. Likewise, there are differences in how NVMe and PV devices handle I/O requests; the former has a timeout value, while the latter does not.