When Is Amazon EC2 Instance Store Data Permanently Erased?

An Amazon EC2 instance store provides temporary block-level storage that is physically attached to the host computer running your virtual machine. Data on an instance store volume is permanently erased whenever the instance stops, hibernates, or terminates, as well as when the underlying physical drive fails. Conversely, data persists across operating system reboots and while the instance remains in the running state. Understanding these specific lifecycle transitions is critical for preventing unintended data loss in cloud architectures.

How Amazon EC2 Instance Store Volumes Work

An instance store consists of one or more physical disks, such as Non-Volatile Memory Express (NVMe) SSDs, solid-state drives (SSDs), or hard disk drives (HDDs), directly attached to the physical hypervisor host where your EC2 instance resides. Unlike Amazon Elastic Block Store (EBS) volumes, which are network-attached storage devices managed independently from the compute host, instance store volumes are tightly coupled to the lifecycle of the underlying hardware allocation.

Because the storage is physically located on the host server, instance store volumes deliver very high random input/output operations per second (IOPS) and low latency. However, this physical dependency means the storage is ephemeral. The data exists only for the duration of the specific instance allocation on that exact physical host.

Lifecycle Transitions That Erase Instance Store Data

Data stored on an Amazon EC2 instance store volume is permanently lost whenever an instance undergoes a transition that deallocates it from its current physical host server or powers down the local storage media.

Stopping an Instance

When you transition an EBS-backed instance from the running state to the stopping and stopped states, Amazon EC2 shuts down the virtual machine and releases the underlying physical host resources back into the available pool of AWS infrastructure. When you start the instance again later, AWS typically provisions it on a completely different physical host server. Because the instance store volumes were physically attached to the original host server, the new host has its own blank local storage, and the previous instance store blocks are cryptographically erased before being allocated to any other customer.

Hibernating an Instance

When an instance enters the hibernation process (stopping to stopped via hibernation), Amazon EC2 signals the operating system to save the contents of the instance memory (RAM) to the root Amazon EBS volume before powering down the virtual machine. Once the RAM state is written to the root EBS volume, the instance is deallocated from the physical host just like a standard stop operation. Although the contents of RAM and attached EBS volumes are preserved and restored upon resuming the instance, any data residing on the instance store volumes is permanently lost because the instance loses its binding to the physical host.

Terminating an Instance

When an instance transitions to the shutting-down and terminated states, the virtual machine is permanently deleted and all associated host resources are released. Any instance store volumes attached to that instance are immediately unmounted and wiped. Whether termination is initiated manually by an administrator, triggered by an Amazon EC2 Auto Scaling group scale-in event, or caused by an EC2 Spot Instance interruption configured to terminate, all data on the instance store is permanently destroyed.

Underlying Hardware or Disk Failure

Although not a user-initiated state transition, a failure of the underlying physical disk or the host server itself will also result in the permanent loss of instance store data. Unlike Amazon EBS volumes, which automatically replicate data across multiple servers within an Availability Zone to protect against single-drive failures, instance store volumes have no built-in redundancy unless you manually configure a software RAID array across multiple instance store volumes attached to the same instance. Even with software RAID, a complete host motherboard or power failure that forces the instance to be stopped and restarted on healthy hardware will erase all local instance store volumes.

Lifecycle Transitions That Preserve Instance Store Data

Not every power or state change results in data loss. Instance store data remains intact as long as the instance maintains its reservation on the same physical host hardware.

Rebooting an Instance

Rebooting an instance—whether initiated through the AWS Management Console, the RebootInstances API call, the AWS CLI, or from within the guest operating system using commands like sudo reboot or shutdown -r—preserves all data on instance store volumes. During a reboot, the instance remains in the running state from the perspective of the AWS control plane, never relinquishes its physical host server, and keeps all local storage mappings intact.

Summary of Instance Lifecycle Transitions

Best Practices for Using Instance Store Volumes

Because any stop, hibernate, or terminate transition wipes the volume, you should never rely on an EC2 instance store for persistent, critical, or un-replicated data. Instead, use instance store volumes exclusively for the following workloads:

• Temporary scratch space: Swap files, staging directories, intermediate video rendering files, or large data-processing shuffle files.
• Caches and buffers: Local read/write caches that can be easily rebuilt from a primary database or Amazon S3 bucket if the instance stops.
• Replicated distributed systems: Databases, distributed file systems, or worker nodes (such as Apache Kafka, Elasticsearch, or Hadoop clusters) where data is actively replicated across a fleet of multiple independent instances, ensuring that the loss of a single node's local disk does not result in cluster-wide data loss.