AWS Nitro System: Nitro Cards, the Nitro Hypervisor and the Nitro Security Chip

Why the server is split in two

A classic hypervisor host, such as the Xen hosts EC2 used before Nitro, runs a privileged management domain on the same CPUs as the guests. That domain emulates or paravirtualizes network and disk devices, runs the management agent, and holds a network stack. Each of those jobs takes host CPU time from guests and adds code that an attacker in a guest could target.

Nitro splits the server into two parts. The system main board holds the Intel, AMD or Graviton CPUs and the memory that run customer workloads. The Nitro Cards are separate computers on PCIe, built around AWS-designed SoCs from Annapurna Labs. They implement every outward-facing interface: VPC networking, EBS, local instance storage, and the management API the EC2 control plane uses to start and stop instances. The whitepaper says the cards share the server's power supply and PCIe but are logically isolated from the main board. When there are several cards, they talk to each other over a private internal network.

Nitro Cards: where I/O and encryption happen

The primary card is the Nitro Controller. It is the hardware root of trust for the server and the only gateway between the server and the EC2, EBS and VPC control planes. It manages the firmware of every other component. System firmware lives on an encrypted SSD attached directly to the Controller, and its key is protected by a TPM together with the SoC's secure boot. The Controller's management API is authenticated, authorized per operation, and logged. AWS also states that it used formal methods to prove the API's message parsing free of memory-safety errors.

Specialised cards share the same SoC and base firmware: the Nitro Card for VPC, the Nitro Card for EBS and the Nitro Card for local NVMe storage. They present standard PCIe functions to the main board. Networking appears as the Elastic Network Adapter (ENA), block storage (EBS and instance store) as NVMe, and the serial console as an ordinary serial port. With the hypervisor in use, each function is split into SR-IOV virtual functions, which are assigned directly to VMs. Guest drivers therefore talk to hardware queues with no software switch in between. That is why ENA and NVMe drivers are mandatory on Nitro instance types, and why old AMIs without them fail to boot or come up with no network.

Encryption also happens on the cards. Hardware engines encrypt EBS volumes and local NVMe storage. On newer VPC cards, traffic between supported instance types is encrypted with AES-256-GCM, provided both instances are in the same Region, in the same or peered VPCs, and the traffic does not pass through a load balancer or transit gateway. According to the whitepaper, the keys exist in plaintext only in the cards' protected volatile memory. Neither code on the host CPUs nor AWS operators can read them. In practice, EBS encryption costs no guest CPU, and an unencrypted volume gains no speed over an encrypted one.

The boot chain and the Nitro Security Chip

The Nitro Controller secures itself through secure boot. Its boot ROM measures and verifies each firmware stage, records the measurements in a TPM, and compares them with a signed known-good set. If anything differs, the data needed to continue booting is not decrypted and the server is pulled from service. That chain covers the card. The Nitro Security Chip extends it to the main board.

The chip sits on the main board and, at runtime, intercepts every operation on non-volatile storage and on low-speed management buses such as SPI and I2C. In other words, it stands between the CPUs and all firmware. It also sits on the PCIe path between the BMC and the CPU, so that interface can be firewalled. The Controller drives the chip, so every firmware update has to go through the Controller's validation.

The chip also controls the reset pins of the CPUs and the BMC. At power-on the Controller finishes its own secure boot, verifies the BIOS and BMC firmware, and only then tells the chip to release the CPUs. The software consequence is that a bare-metal tenant with full ring-0 access still cannot flash the BIOS to persist malware for the next tenant. That guarantee is what makes renting bare metal safe for AWS. When a hypervisor is present, the chip is a second layer of defence.

The Nitro Hypervisor and bare metal

With the I/O work moved to the cards, the hypervisor has little left to do. According to the whitepaper, the Nitro Hypervisor receives VM commands (start, stop) from the Controller, partitions CPU and memory with the processor's hardware virtualization, assigns SR-IOV virtual functions and accelerators such as GPUs to VMs, and recovers from hardware errors. By design it has no networking stack, no general-purpose filesystem, no peripheral device drivers, no shell and no interactive access. It is signed firmware stored on the Controller's encrypted SSD. The Controller hands it to the main board as a read-only NVMe boot device. The hypervisor can also be live-updated in place while instances keep running.

The security whitepaper does not describe the hypervisor's code base, so treat third-party claims about its internals with care. For software, the observable effects matter more. Little host CPU is taken from guests, there is no noisy dom0 competing for cycles, and jitter is lower. A bare-metal instance (.metal) is the same server without the hypervisor. You keep ENA, EBS-over-NVMe, encryption and the management plane, because those live on the cards, and you gain direct access to hardware features such as performance counters and nested virtualization.

What software can see from inside an instance

From inside an instance you can confirm all of the above. Start with the platform type, then look at the devices and the counters the cards expose.

# Which hypervisor does an instance type use? (nitro, xen, or empty for bare metal)
aws ec2 describe-instance-types --instance-types m7i.large c5.metal \
  --query 'InstanceTypes[].[InstanceType,Hypervisor,BareMetal]' --output table

# The Nitro devices as the guest sees them
lspci | grep -i amazon          # Elastic Network Adapter, NVMe EBS controller, ...
ethtool -i eth0 | head -3       # driver: ena
sudo nvme list                  # EBS volumes and instance store as NVMe namespaces

# Map an NVMe namespace back to its EBS volume id (serial number is vol0123...)
sudo nvme id-ctrl -v /dev/nvme1n1 | grep -E '^(sn|mn)'
ls -l /dev/disk/by-id/ | grep Amazon_Elastic_Block_Store

# ENA reports when the instance hits a per-instance allowance enforced on the card
ethtool -S eth0 | grep -E 'allowance_exceeded'
#   bw_in_allowance_exceeded, bw_out_allowance_exceeded, pps_allowance_exceeded,
#   conntrack_allowance_exceeded, linklocal_allowance_exceeded

The allowance counters matter most for operations. The VPC card enforces per-instance limits on bandwidth, packets per second, tracked connections and link-local traffic (DNS, the metadata service, NTP). When a limit is hit, packets are queued or dropped on the card before the guest kernel sees them, so netstat looks clean while the counter increases. Graph these counters as rates in your monitoring agent. A non-zero rate explains latency spikes that no in-guest tool will show you.

For storage, remember that EBS is a network service presented as an NVMe controller. The Linux NVMe driver has an I/O timeout, nvme_core.io_timeout. If that timeout is shorter than an occasional EBS stall, the kernel resets the controller and may remount the filesystem read-only. AWS's EBS documentation recommends setting it to the maximum value, and current Amazon Linux AMIs already do. Check custom images.

Worked example: a latency cliff the guest cannot see

Consider an illustrative case. A DNS-heavy ingestion service on a mid-size compute instance reports p99 latency rising from 4 ms to 300 ms at peak, while CPU stays at 35% and network throughput is a fraction of the instance's rating. In-guest tools show no drops.

1. Collect ethtool -S eth0 every 10 seconds. pps_allowance_exceeded stays flat, but linklocal_allowance_exceeded climbs by thousands per minute at peak.
2. Link-local traffic includes queries to the VPC resolver at the link-local address. The service resolves a hostname for every request with no caching, so the per-ENI link-local packet allowance is exhausted and the card drops excess queries. Each dropped query costs a resolver retry timeout.
3. Fix: run a local caching resolver, or cache inside the application, and reuse connections. The counter drops to zero and p99 returns to about 5 ms with no change of instance size.
4. If pps_allowance_exceeded had been the counter climbing, the right fixes would have been larger packets (batching, jumbo frames inside the VPC), more ENIs and queues, or a larger instance. Adding CPU does not help, because the limit is enforced on the card.

The lesson generalises. On Nitro, several limits that look like host limits are enforced on a card, and the card reports them only through its own counters. Learn where those counters are before an incident.

Failure modes

None of these failures is a Nitro defect. Each comes from treating Nitro devices as if they were the emulated devices of older platforms.

Trade-offs: virtualized, bare metal and enclaves

Nitro Enclaves is a further option. It carves vCPUs and memory out of a parent instance into an isolated VM with no network or persistent storage, reachable only over vsock, that can present a signed attestation document to AWS KMS. That is a separate design topic covered in Nitro Enclaves. NitroTPM, a TPM 2.0 device for instances that boot with UEFI, supports measured boot and disk-key sealing inside the guest, using the same trust-anchor idea as the Controller.

What to do next

1. Run the describe-instance-types query for every type in your fleet and flag any that still report xen.
2. Audit AMIs for ENA and NVMe drivers and mount by UUID. Read the EC2 guide for the launch-side checklist.
3. Export the five ENA allowance counters as rate metrics and alert on any sustained non-zero rate.
4. Check nvme_core.io_timeout in custom images, and review volume choices with EBS and EBS volume types.
5. Turn on EBS encryption by default with a key policy from AWS KMS. On Nitro the cost is effectively zero.
6. For HPC or ML networking, read EFA on AWS, which uses the same card-offload model for OS-bypass traffic.