Does Rebooting an EC2 Instance Erase NVMe Instance Store Data?

When an Amazon EC2 instance equipped with local NVMe instance store volumes is rebooted from inside the guest operating system, all data stored on those volumes is preserved. Unlike stopping or terminating an instance, an operating system level reboot maintains the instance on the same underlying physical host hardware, ensuring that the temporary block-level storage remains intact and accessible once the system finishes restarting. This article explores the mechanics of EC2 instance store persistence, the critical differences between rebooting and stopping an instance, how hardware encryption behaves during a restart, and the operating system configurations required to automatically remount NVMe volumes upon boot.

Understanding EC2 NVMe Instance Store Architecture

An Amazon EC2 instance store provides temporary block-level storage for your instance. Unlike Amazon Elastic Block Store (EBS), which is network-attached storage that persists independently of the compute lifecycle, instance store volumes are physically attached to the host computer that runs the EC2 instance. On modern EC2 instance families (such as Nitro-based instances), these volumes are backed by Non-Volatile Memory Express (NVMe) solid-state drives (SSDs) that deliver high random I/O performance and very low latency.

Because the storage media is directly connected to the physical host server's PCIe bus, the lifecycle of the data on an NVMe instance store volume is strictly bound to the lifecycle of the instance's association with that specific physical host. As long as the virtual machine remains scheduled on the same physical hardware and the underlying drive does not fail, the data on the NVMe devices remains intact.

Guest OS Reboots vs API Reboots

When you initiate a reboot from inside the guest operating system—using commands such as sudo reboot, sudo shutdown -r now, or systemctl reboot on Linux, or Restart-Computer on Windows—the operating system cleanly shuts down running services, flushes file system buffers to the disk, and instructs the virtual machine firmware to reset.

From the perspective of the AWS Nitro hypervisor, a guest-initiated reboot is identical in outcome to an API-initiated reboot (aws ec2 reboot-instances). In both scenarios:

1. Physical Host Persistence: The EC2 instance stays on the exact same physical host server. It is not migrated to another hardware node in the data center.
2. Network and Storage Continuity: The instance retains its private and public IPv4 addresses, IPv6 addresses, network interfaces, and direct physical mapping to the local NVMe SSDs.
3. Power State: The underlying NVMe drives remain powered on and connected to the host throughout the guest restart sequence.
4. Billing Continuity: No new billing transition occurs because the instance never leaves the running state in the AWS control plane (though it briefly appears unreachable over the network while the OS kernel reloads).

What Happens to NVMe Encryption Keys During a Reboot?

Data on NVMe instance store volumes is automatically encrypted using an XTS-AES-256 block cipher implemented directly in hardware on the Nitro controller module. Each NVMe instance store device has its own unique encryption key generated when the instance is first launched and assigned to the host hardware.

During an in-guest reboot, these hardware encryption keys are not destroyed or regenerated. Because the instance remains active in its running placement slot on the Nitro card, the hardware encryption module retains the cryptographic keys in volatile controller memory. When the guest operating system boots back up and the NVMe driver initializes /dev/nvme1n1 (or equivalent device nodes), the controller seamlessly decrypts blocks read from the drive just as it did prior to the reboot.

Encryption keys are only destroyed when the instance enters the stopped or terminated state, or if the underlying physical disk experiences an unrecoverable hardware failure.

Comparing EC2 Lifecycle Actions and Data Persistence

Understanding which lifecycle transitions preserve or wipe local NVMe storage is critical for preventing unintended data loss.

The Danger of shutdown -h or poweroff Inside the Guest

A common operational mistake occurs when an administrator executes shutdown -h now or poweroff instead of reboot from inside the guest operating system. By default, when an EBS-backed EC2 instance halts its operating system, the AWS hypervisor detects the ACPI power-down state and transitions the EC2 instance state from running to stopped (or terminated, depending on the InstanceInitiatedShutdownBehavior attribute).

Once the instance transitions to the stopped state:

• The instance is deallocated from the physical host.
• The Nitro controller destroys the NVMe hardware encryption keys, rendering all blocks on the local NVMe drives permanently unreadable.
• When you subsequently start the instance, it is provisioned on a new physical host with freshly wiped NVMe instance store volumes.

Operating System Considerations Upon Reboot

While the raw block data and file systems on the NVMe instance store volumes survive a guest OS reboot, the operating system does not automatically mount extra block devices unless explicitly configured to do so.

1. Persistent Mounting with /etc/fstab

If you format and mount an NVMe instance store volume manually (for example, mount /dev/nvme1n1 /mnt/ephemeral), that mount exists only in the current kernel session. After a reboot, the data will still be sitting on /dev/nvme1n1, but /mnt/ephemeral will be an empty directory on the root volume until the drive is mounted again.

To ensure the volume automatically remounts during the boot sequence, add an entry to /etc/fstab using the file system's UUID rather than the kernel device name:

UUID=12345678-abcd-1234-ef00-123456789abc  /mnt/ephemeral  xfs  defaults,nofail  0  2

2. Why Device Names and nofail Matter

On Linux kernels, NVMe device node names (/dev/nvme0n1, /dev/nvme1n1, /dev/nvme2n1) are assigned asynchronously as the PCIe bus is scanned during boot. If your instance has both EBS volumes (which also appear as NVMe devices on Nitro instances) and local NVMe instance store volumes, /dev/nvme0n1 might become /dev/nvme1n1 across reboots. Mounting by UUID= or file system LABEL= guarantees the operating system mounts the exact volume you intended.

Additionally, including the nofail mount option in /etc/fstab is mandatory for operational safety on EC2. If the instance is ever stopped and started in the future (or recovered onto new hardware), the NVMe instance store volume will come up unformatted without a file system or matching UUID. Without nofail, the Linux boot process will halt in emergency mode waiting for the missing UUID, locking you out of SSH access.

3. Automating Initialization with Systemd or Cloud-Init

Because an instance might eventually be stopped and started—which wipes the file system on the NVMe volume—many production environments configure a startup script or systemd unit that runs before application services start. This script checks if a valid file system exists on the local NVMe instance store device using blkid or lsblk -f:

• On a standard reboot: The script sees the existing file system, skips formatting, and mounts the volume with all prior data intact.
• After a stop/start cycle: The script detects an unformatted raw device, runs mkfs.xfs or mkfs.ext4, creates the required directory structure, and mounts the clean volume.

Best Practices for Workloads Using NVMe Instance Store

Even though NVMe instance store data survives in-guest reboots, it should always be treated as ephemeral storage. To maintain high availability and data durability:

• Use for Scratch Data and Caches: Store temporary processing files, swap space, database buffer pool extensions, or read-through caches that can be reconstructed from durable sources (like Amazon S3 or Amazon EBS) if the host fails.
• Replicate Across Availability Zones: If running distributed databases or stateful clusters (such as Apache Cassandra, Kafka, or Elasticsearch/OpenSearch) on NVMe instance store volumes, rely on application-level replication across multiple instances in separate Availability Zones so that a single host failure or stop event does not cause cluster-wide data loss.
• Flush Buffers Before Forced Reboots: Always prefer graceful OS reboot commands (sudo reboot) over hard resets so the guest kernel can flush dirty pages from system memory (pagecache) and NVMe volatile write caches down to non-volatile NAND flash media before the reset occurs.