An instance store provides temporary block-level storage for your instance. This storage is located on disks that are physically attached to the host computer. You can specify instance store volumes for an instance only when you launch it.If you create an AMI from an instance, the data on its instance store volumes isn’t preserved and isn’t present on the instance store volumes of the instances that you launch from the AMI.You can’t detach an instance store volume from one instance and attach it to a different instance.
Differences of EBS root & Instance store
| Characteristic | EBS (default root) | Instance store (a.k.a. “ephemeral”, “local NVMe/SSD”) |
|---|---|---|
| Where it lives | Network‑attached SAN inside the AZ | Physically inside the host server |
**Persists after **Stop/Terminate
|
💾 Yes (unless you tick “Delete on termination”) | ❌ No – wiped the moment the instance stops, fails, or is terminated |
| Provisioned automatically? | Root volume always, extra EBS optional | Only if you choose an instance family that advertises local disks (the ones with a d suffix, e.g., c7gd, m7i-flex, i4i, im4gn, “storage‑optimized” I/D types, etc.) |
| Shows up as |
/dev/xvda, /dev/nvme0n1 (for Nitro) plus any additional EBS you attach |
/dev/nvme1n1, /dev/nvme2n1, … (empty, must be formatted/mounted) |
| When to use | OS, databases, anything you must keep | Temp caches, scratch space, shuffle files, build artifacts, buffer for streaming data |
Think of EBS as a durable external hard drive that follows the instance around,
Instance store as a lightning‑fast notepad left on the desk that’s tossed when you leave the room.
2 ️Why you always get an EBS volume
- Boot requirements – The public Amazon Linux, Ubuntu, Windows, and most marketplace images are created as EBS‑backed AMIs. They simply expect an EBS root, so AWS creates one automatically at launch.
-
Predictable persistence – If you stop an instance (e.g., overnight cost‑saving) the root disk must still hold
/etc, registry, app binaries, etc. Instance store would vanish; EBS survives.
3 ️When you’ll also see instance‑store disks
-
You deliberately pick an instance type that includes them, such as:
-
Compute‑optimized with local SSD:
c7gd,c6id -
General‑purpose with local SSD:
m7gd,m6id -
Storage‑optimized:
i4i,i3en,d3en -
Bare‑metal or GPU families (
p5d,g6id, …)
-
Compute‑optimized with local SSD:
-
The console shows “Instance store volumes: 1 x 1900 GB NVMe SSD” (numbers vary).
-
Inside the OS they appear as additional, blank block devices. You need to:
sudo mkfs.xfs /dev/nvme1n1 # one‑time format
sudo mkdir /mnt/ephemeral
sudo mount /dev/nvme1n1 /mnt/ephemeral
and (optionally) add an /etc/fstab entry.
If you stop or terminate the instance, everything under /mnt/ephemeral is gone, while /dev/xvda (EBS) is still sitting safely in your account.
4 ️Choosing the right combination
| Requirement | Practical choice |
|---|---|
| I just need a normal VM (web server, app tier, database) | Keep the default EBS root; maybe add extra EBS for data. Don’t worry about instance store. |
| I need massive IOPS & lowest latency for temporary data (HPC scratch, Spark shuffle, ML tensor checkpoints) | Choose a *d or storage‑optimized family so you get NVMe instance store. Still keep EBS for the OS and anything you must preserve. |
| I want everything to persist even after a stop/terminate | Use only EBS volumes and avoid families with mandatory local disks. |
| I want the root volume to be *ephemeral* | Launch from a legacy “instance‑store‑backed AMI” (rare nowadays) or build your own and set the root device to ephemeral0. Almost never recommended unless you truly want stateless boot‑from‑scratch behaviour. |