What is the AWS Nitro system, and what does running on Nitro-based EC2 instance types change for the operating system and AMI you boot?

## What Nitro replaced EC2 originally ran on a modified Xen hypervisor. That hypervisor did a great deal of work on the host CPU: emulating network devices, translating block-storage requests, handling management operations. Every cycle it spent was a cycle you paid for and did not get, and the software surface between tenants was large. The Nitro system moves that work off the main processor and onto **purpose-built hardware cards**, with three broad pieces: 1. **Nitro cards** — separate hardware handling VPC networking, remote block storage, local NVMe storage, and instance monitoring and management. From the guest's point of view these appear as ordinary PCI devices. 2. **The Nitro security chip** — integrated into the motherboard, it takes over hardware access control and establishes a hardware root of trust for the host's firmware, so host firmware cannot be modified by anyone, including AWS operators, without detection. 3. **The Nitro hypervisor** — a very thin KVM-based component whose only remaining job is memory and CPU allocation. Since the devices are real hardware rather than emulations, it has almost nothing to do at steady state. The result is that a Nitro instance delivers essentially all of the host's compute and memory to guests, with performance close to bare metal. ## What it enables Several EC2 features exist only because of this design: - **Bare-metal instance types** (`.metal`). If the network and storage devices are already real hardware, you can hand a customer the whole machine with no hypervisor at all and they still get VPC networking and remote block storage. That is what makes nested virtualisation and per-socket-licensed software possible on EC2. - **Nitro Enclaves** — isolated compute environments carved out of an instance with no persistent storage, no interactive access and no external networking, for processing sensitive data. - **Higher device performance** generally: enhanced networking through the Elastic Network Adapter (ENA) and storage presented over NVMe. As of 2025, effectively all current-generation instance types are Nitro-based, so "is it Nitro?" is mostly a question about how old the type you are considering is. ## What actually changes for you The abstraction is good enough that most people never think about it — until one of these bites. **Device naming.** Block devices are exposed as NVMe devices. You may request an attachment at `/dev/sdf`, but inside the guest it shows up as `/dev/nvme1n1`, and **the numbering follows attachment order, which is not guaranteed across reboots**. Any `/etc/fstab` entry or automation keyed on a device path is a latent failure. Mount by filesystem UUID or label instead: ```bash lsblk -o NAME,SIZE,FSTYPE,UUID,MOUNTPOINT blkid /dev/nvme1n1 # /etc/fstab: use the UUID, never the device node # UUID=1a2b3c4d-... /var/lib/data xfs defaults,nofail 0 2 ``` On Amazon Linux the `ebsnvme-id` helper maps an NVMe device back to the volume and the name you originally requested, which is how you correlate what the guest sees with what the API says. **Drivers in the AMI.** The image must include the ENA driver for networking and NVMe drivers for storage. Every current Amazon Linux, Ubuntu, Windows and RHEL image ships them. The failure mode appears when someone migrates a hand-built or long-lived custom image forward onto a modern instance type: the instance launches and then fails its status checks or comes up with no network, because the kernel has no driver for the devices Nitro presents. **Reboot and maintenance behaviour.** Because so much lives on separate cards, AWS can update host software with far less disruption than the old model required — one reason live-update maintenance notices are rarer than they used to be. ## How to answer this in an interview Most candidates can say "Nitro is AWS's hypervisor." The distinguishing answer explains **why the offload matters** — more of the host goes to the guest, the isolation boundary is hardware rather than software, and bare metal becomes possible — and then names one concrete operational consequence, which is almost always the NVMe device-naming trap. That combination shows you have both read about it and run something on it.