Instance Store vs EBS

When you run an EC2 instance (a virtual server in Amazon’s cloud), it needs disks to store data. AWS gives you two very different kinds of disk: instance store and EBS (Elastic Block Store). Instance store is a physical disk built into the actual host computer your instance runs on — it is blazing fast, but the data vanishes the moment the instance stops or moves. EBS is a network-attached disk that lives separately and survives almost anything. Picking the wrong one is one of the most common (and painful) mistakes new cloud engineers make, so this page explains exactly how they differ and when each fits.

What is instance store?

Instance store (sometimes called an “ephemeral disk” or “local NVMe”) is storage made of disks physically attached to the host server — the real hardware machine your virtual instance happens to run on. Because the data never leaves that box, reads and writes are extremely fast (modern instances use NVMe SSDs, a very fast type of flash storage).

The catch is right there in the word ephemeral (meaning short-lived): the data is tied to that specific host. If your instance leaves the host for any reason, the data is gone forever. There is no recovery and no snapshot.

Warning: Instance-store data is lost when you stop, terminate, or hibernate the instance, or when the underlying hardware fails. It is NOT lost on a simple reboot. Never store anything on instance store that you cannot afford to lose.

Also important: not every instance type has instance store. Many general-purpose types (like t3 or t4g) have no local disk at all and rely entirely on EBS. Only specific families (such as i4i, i3, m7gd, c7gd, r7gd — the ones with a d in the name) include it.

What is EBS?

EBS (Elastic Block Store) is a network-attached disk. The data lives on a separate, highly redundant storage system inside the Availability Zone (a data-center location), and your instance talks to it over the network. Because it is decoupled from the host:

• The data survives stop, start, and termination (when “delete on termination” is off).
• You can detach a volume from one instance and attach it to another.
• You can take snapshots (point-in-time backups stored in S3) for backup and cloning.

EBS is the default boot disk (root volume) for nearly all instances and is where almost all real, must-keep data belongs.

Instance store vs EBS — when to use which

Aspect	Instance store	EBS (gp3 / io2)
Physical location	On the host server	Network-attached, separate system
Survives reboot	Yes	Yes
Survives stop / terminate	No	Yes
Survives hardware failure	No	Yes (replicated within the AZ)
Snapshots / backups	No	Yes
Detach & re-attach	No	Yes
Performance	Highest (local NVMe)	Very high, but over the network
Available on all types?	No (only *d / storage types)	Yes
Cost	Included in instance price	Billed per GB-month + IOPS

Use instance store for data you can rebuild or lose without harm:

• Caches and buffers.
• Scratch space for temporary processing (video transcoding, ML preprocessing).
• Local copies of data that already lives somewhere durable.
• One node of a replicated system (e.g. a database cluster) where other copies hold the truth.

Use EBS for anything that must persist: operating system root volumes, databases, application files, logs you need to keep, and any data without a second copy.

How to use instance store (console)

You attach instance store at launch by picking an instance type that includes it — you cannot add it later.

1. Open the EC2 console and choose Launch instances.
2. Under Instance type, pick a type with local storage, e.g. i4i.large or m7gd.large.
3. Expand Configure storage → Advanced. You will see the instance-store volumes listed (e.g. ephemeral0) in addition to the EBS root volume.
4. Launch the instance, connect to it, and the local NVMe disk appears as an unmounted block device (e.g. /dev/nvme1n1). You must format and mount it yourself.

After connecting via SSH, prepare the disk:

# List block devices to find the instance-store NVMe disk
lsblk

# Format it with a filesystem and mount it
sudo mkfs -t xfs /dev/nvme1n1
sudo mkdir -p /mnt/scratch
sudo mount /dev/nvme1n1 /mnt/scratch

Output:

NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
nvme0n1       259:0    0    8G  0 disk
└─nvme0n1p1   259:1    0    8G  0 part /
nvme1n1       259:2    0  468G  0 disk          <- instance store, empty

Tip: Do not add the instance-store mount to /etc/fstab without the nofail option. If the disk is empty after a stop/start (which it always will be), a hard fstab entry can block the instance from booting.

How to use instance store (AWS CLI)

The local disk is defined automatically by the instance type, but you can confirm it from your machine using AWS CLI v2.

aws ec2 run-instances \
  --image-id ami-0abcdef1234567890 \
  --instance-type i4i.large \
  --key-name my-key \
  --security-group-ids sg-0a1b2c3d \
  --subnet-id subnet-0a1b2c3d \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=scratch-node}]'

Output:

{
    "Instances": [
        {
            "InstanceId": "i-0a1b2c3d4e5f",
            "InstanceType": "i4i.large",
            "InstanceLifecycle": "on-demand",
            "State": { "Name": "pending" }
        }
    ]
}

To check which instance types include instance store before launching:

aws ec2 describe-instance-types \
  --instance-types i4i.large \
  --query "InstanceTypes[].InstanceStorageInfo"

Output:

[
    {
        "TotalSizeInGB": 468,
        "Disks": [ { "SizeInGB": 468, "Count": 1, "Type": "ssd" } ],
        "NvmeSupport": "required"
    }
]

If the result is an empty [], that type has no instance store and you must use EBS.

Cost note

Instance store has no separate charge — its capacity is baked into the hourly price of the instance type. EBS, by contrast, is billed per GB-month plus provisioned IOPS. As a rough 2026 guide, a 500 GB gp3 EBS volume costs around $40/month whether the instance is running or stopped. So instance store can look “free,” but remember you are paying for it inside a pricier instance family and you get zero durability for that money.

Best practices

• Treat instance store as disposable scratch space only — assume the data will disappear at any moment.
• Never put the root volume, databases, or unbacked files on instance store; use EBS for anything that must survive a stop.
• Check describe-instance-types (or the console) before launching to confirm the type actually has local storage.
• Add a startup script (user data) that re-formats and re-mounts the instance-store disk on every boot, since it is wiped on stop/start.
• If you need durability and local-disk speed, keep the source of truth in EBS, S3, or a replicated cluster and use instance store only as a fast local copy or cache.
• Use nofail in /etc/fstab for instance-store mounts so a missing disk never blocks the boot.

Related Topics

• EBS volumes
• EBS snapshots
• Instance types
• Choosing an instance type
• Instance lifecycle