How Does AWS Nitro Encrypt EC2 NVMe Instance Store Drives?

AWS Nitro System provides always-on, line-rate hardware encryption for all Amazon EC2 NVMe instance store drives using dedicated Nitro Cards. These custom-designed hardware controllers execute XTS-AES-256 encryption and decryption transparently in transit between the host processor and the physical non-volatile memory express media. Ephemeral encryption keys are generated inside hardware security modules on the Nitro Card during instance launch and are permanently destroyed when the instance stops or terminates, ensuring complete cryptographic erasure and preventing unauthorized data recovery across multi-tenant cloud infrastructure.

The Architecture of the AWS Nitro Controller for Local NVMe Storage

The AWS Nitro System offloads virtualization, networking, and storage management from the primary host CPU onto purpose-built hardware components. For local instance store volumes, the dedicated Nitro Card for NVMe Storage acts as the physical intermediary between the instance's guest operating system and the underlying solid-state drives attached to the server motherboard.

Unlike traditional hypervisor-based storage emulation, the Nitro Card presents physical NVMe devices directly to the guest instance via Single Root I/O Virtualization (SR-IOV) over the PCIe bus. When an application writes data to a local NVMe block device, the guest operating system issues standard NVMe I/O commands over PCIe. These transactions are intercepted by the custom Application-Specific Integrated Circuit (ASIC) on the Nitro Card before reaching the physical flash media. Because the cryptographic engine resides directly in the hardware data path on the Nitro ASIC, encryption requires zero host CPU cycles, consumes no host memory, and introduces no measurable latency penalty.

Line-Rate XTS-AES-256 Hardware Encryption

To protect data at rest on high-throughput block storage without degrading performance, AWS Nitro implements the XEX-based tweaked-codebook mode with ciphertext stealing and the Advanced Encryption Standard with a 256-bit key (XTS-AES-256), as standardized in IEEE P1619.

In XTS-AES-256 mode, the hardware engine uses a 512-bit master key split into two independent 256-bit keys:

\[K = K_1 \parallel K_2\]

Here, \(K_1\) encrypts the actual plaintext data block, while \(K_2\) encrypts a sector-specific tweak value \(i\) (typically derived from the logical block address) to ensure that identical plaintext blocks written to different disk sectors produce completely different ciphertexts. For a given 128-bit data block \(P_j\) at index \(j\) within sector \(i\), the ciphertext \(C_j\) is computed using modular multiplication in the Galois Field \(\text{GF}(2^{128})\) with the primitive polynomial \(\alpha\):

\[T = E_{K_2}(i) \otimes \alpha^j\]

\[C_j = E_{K_1}(P_j \oplus T) \oplus T\]

Because the tweak calculation for each 128-bit block index \(j\) within a sector is independent of adjacent blocks, the Nitro ASIC can parallelize the AES encryption rounds across multiple hardware pipelines. This architectural design allows the Nitro Card to sustain line-rate encryption and decryption across multiple gigabytes per second of sequential and random I/O throughput.

Ephemeral Key Generation and Lifecycle Management

Security on shared physical storage relies heavily on strict cryptographic isolation between consecutive tenants. AWS Nitro enforces this isolation through an automated, hardware-isolated ephemeral key lifecycle that operates without human or hypervisor intervention.

  1. Hardware Key Generation: When an EC2 instance with NVMe instance store volumes is launched, a True Random Number Generator (TRNG) embedded within the Nitro Card generates a unique XTS-AES-256 key pair for each physical NVMe namespace allocated to the instance.
  2. Volatile Key Storage: The generated keys are held exclusively in isolated, volatile static RAM (SRAM) registers inside the Nitro ASIC's cryptographic boundary. The keys are never written to non-volatile flash memory, cannot be exported over the PCIe bus, and are inaccessible to the guest OS, the Nitro Hypervisor, or AWS operators.
  3. Active I/O Operations: Throughout the running lifecycle of the instance—including guest OS reboots—the keys remain intact in the Nitro Card's volatile memory, transparently encrypting writes and decrypting reads.
  4. Cryptographic Erasure on Termination: When the EC2 instance enters a stopped or terminated state, the Nitro System immediately zeroes out the volatile key registers on the Nitro Card. In the event of an unexpected physical host power loss, the volatile SRAM loses power and the keys dissipate instantly.

Once the ephemeral key is destroyed, any residual ciphertext remaining on the physical NAND flash cells becomes permanently indecipherable, satisfying NIST SP 800-88 standards for cryptographic sanitization before the drive is provisioned to another customer.

Protection Against Physical and Firmware-Level Threats

Beyond data-at-rest encryption, the AWS Nitro System combines its storage encryption pipeline with strict hardware root-of-trust mechanisms developed around the Nitro Security Chip.

DMA and PCIe Bus Isolation

Because the guest operating system interacts with a virtualized PCIe function managed by the Nitro Card rather than the raw drive controller on the SSD itself, the instance cannot issue vendor-specific NVMe commands to manipulate drive firmware. Furthermore, the Nitro Card enforces strict Input-Output Memory Management Unit (IOMMU) and Direct Memory Access (DMA) protections, ensuring an instance can only read or write to memory regions explicitly mapped to its own virtual address space.

SSD Firmware Isolation

Even if a physical NVMe drive experiences a hardware failure and is removed from an AWS data center for disposal or third-party warranty replacement, the drive contains only XTS-AES-256 ciphertext. Because the encryption keys never leave the Nitro Card on the host motherboard and are never passed to the SSD's internal controller (unlike standard self-encrypting drives that store keys in internal flash wrapped by an authentication pin), physical possession of the NVMe drive yields no cryptographic material.

Operational Characteristics for Cloud Workloads

Because NVMe instance store encryption is enforced at the hardware layer by the Nitro System, its operational behavior differs significantly from Amazon Elastic Block Store (EBS) encryption:

  • Always-On Enforcement: Hardware encryption on Nitro NVMe instance store volumes cannot be disabled by the user. Every byte written to the local NVMe drive is encrypted by default.
  • No AWS KMS Integration: Because instance store data is ephemeral and tied strictly to the lifecycle of a single physical host, Nitro does not use AWS Key Management Service (KMS) or customer-managed keys (CMKs) for local NVMe drives.
  • Sub-Millisecond Latency: By avoiding network-attached key lookups and software cryptographic layers (such as Linux dm-crypt or LUKS), Nitro NVMe encryption delivers bare-metal I/O latency and maximum IOPS for high-performance databases, real-time analytics caches, and distributed file systems.