Skip to main content
This lesson demonstrates how Amazon Elastic Compute Cloud (EC2) instance store volumes behave and highlights their ephemeral nature. Key takeaway: when an EC2 instance moves to a different physical host (for example, after a stop/start), any data on the instance store is lost because the instance receives a new instance store. Use instance store only for temporary or scratch data that you can afford to lose.
Instance store volumes are ephemeral. If your instance is stopped and then started (which can move it to a different physical host), the instance store is replaced and all data on it is lost. To persist data you should use EBS or attach external storage that persists across host changes.
We’ll walk through these steps:
  1. Launch an instance that includes an instance store volume.
  2. Inspect block devices on the instance.
  3. Create a filesystem on the instance store and mount it.
  4. Reboot the instance to show the same instance store remains (but mounts are not persisted).
  5. Stop and start the instance to show the instance store is replaced and data is lost.
Start by launching an EC2 instance with Amazon Linux 64-bit.
Screenshot of the AWS EC2 "Launch instance" page. It shows AMI selection (Amazon Linux highlighted), instance type t2.micro, and a summary panel with a "Launch instance" button.

​
Important notes about instance types and billing

  • Instance store is supported only on certain instance types. Look for instance families that expose instance store (for example, Nitro-based instances with an “d” suffix such as m5d, or other instance types that explicitly list instance store in their storage options).
  • Free Tier instance types (e.g., t2.micro) generally do not include instance store volumes, so choose a supported instance type if you need instance store — this may incur charges.
When configuring storage during instance launch, you’ll see the root volume and the instance store on the storage configuration page. In this example there is an 8 GiB root volume and a 75 GiB instance store device.
A screenshot of the Amazon Web Services EC2 instance launch/configure storage page. It shows storage settings (root volume size/type and instance store details) on the left and a Summary panel on the right with AMI, instance type, storage totals and a "Launch instance" button.

​
Inspect block devices on the instance

After launching the instance, ensure it has a public IP (auto-assigned or an Elastic IP if you need a stable address). SSH into the instance and inspect block devices:
  • The root volume appears as nvme0n1 (e.g., nvme0n1p1 mounted at /).
  • The instance store device shows up as a raw block device (for example, nvme1n1) with no filesystem.
Verify there is no filesystem on the instance store device:

​
Create and mount a filesystem on the instance store

Create an XFS filesystem on the instance store device and mount it:
Mount the filesystem and confirm it is mounted:
Create a small test file to demonstrate data persistence (or lack thereof):

​
Reboot vs Stop/Start — what changes the physical host?

A common confusion is whether a reboot moves an instance to a different physical host. Rebooting the EC2 instance does NOT move it to a different host — it restarts the VM on the same host. Therefore, data on the instance store remains intact after a reboot. However, mount operations performed with mount are not persisted; they are temporary and will be lost after a reboot unless you add an appropriate entry to /etc/fstab. To illustrate that reboot does not change the host, reboot the instance from the EC2 console:
A screenshot of the Amazon EC2 management console showing a list of running instances (including "instance-store-demo" and "test") and the details pane for the selected instance (instance ID, instance type m5dn.large, IP addresses and status).
After reboot, SSH back in and (if needed) remount the instance store, then confirm the test file still exists:

​
Stop and start — instance store is replaced

Stopping and then starting an EBS-backed instance can place the instance on a different physical host. If that happens, the instance store on the new host will be empty and any data you had on the previous instance store is lost. Stopping and starting also normally changes the auto-assigned public IP unless an Elastic IP is configured. Stop the instance, wait for it to stop, then start it again. After the instance is running, SSH in and inspect block devices:
Because /dev/nvme1n1 reports data, there is no filesystem and the test file we created earlier is gone — the instance store has been replaced.
If you need a stable public IP across stop/start cycles, associate an Elastic IP. If you need persistent storage that survives host changes, use EBS volumes or another persistent storage option. Stopping and starting instances that are not using Elastic IPs will usually change the public IP.

​
Quick summary / exam tips

  • Instance store volumes are ephemeral. Data on instance store can be lost if the instance is moved to another physical host (for example, through stop/start).
  • Rebooting an EC2 instance does not move it to a different host; stop and start can.
  • Mounts performed with mount are temporary. To mount automatically at boot, add an appropriate entry to /etc/fstab.
  • Use EBS (or another persistent storage option) for data that must survive instance stop/start or host failure.
  • If you need a persistent public IP across stop/start, use an Elastic IP.
That concludes this lesson on instance store behavior and how to test it.

Watch Video