Two Very Different Kinds of EC2 Block Storage
Amazon EBS (Elastic Block Store) provides network-attached block volumes that live independently of any single EC2 instance: you can detach a volume, attach it to a different instance, and the data on it persists through instance stop/start and even instance termination (unless you set the volume to delete-on-termination). Instance store, by contrast, is physical disk capacity attached directly to the host server that your EC2 instance happens to be running on; it delivers very high, low-latency IOPS because there is no network hop, but the data is ephemeral — it is lost on stop, terminate, or if the underlying host fails, and it survives only a reboot.
Cricket analogy: It's like the difference between a player's personal kit bag that travels with them to every ground they play at (EBS, portable and persistent) versus the chalk marks a groundstaff paints on one specific pitch that vanish the moment that pitch is relaid (instance store, tied to the physical venue).
Performance and Durability Trade-offs
EBS volumes come in several types — gp3 (general-purpose SSD, baseline 3,000 IOPS/125 MB/s independent of size), io2 Block Express (up to 256,000 IOPS for the most demanding databases), st1 (throughput-optimized HDD for big sequential workloads like log processing), and sc1 (cold HDD for the cheapest infrequent access) — and each volume is itself replicated within its Availability Zone for durability. Instance store, available on certain instance families (like the storage-optimized 'i' or 'd' families), can deliver millions of IOPS at sub-millisecond latency directly off local NVMe SSDs because there's no EBS network stack in the path, but there is no automatic replication: if you need durability, the application itself (e.g., a distributed database doing its own replication) must provide it.
Cricket analogy: It's like choosing between a well-maintained turf pitch prepared days in advance for a Test match (EBS gp3/io2, consistent and durable) versus a quickly rolled practice net pitch that offers blistering pace for one session but isn't preserved afterward (instance store).
# Launch an instance with a gp3 EBS root volume plus an extra io2 volume
aws ec2 run-instances \
--image-id ami-0abcdef1234567890 \
--instance-type r6i.large \
--block-device-mappings '[
{"DeviceName":"/dev/xvda","Ebs":{"VolumeType":"gp3","VolumeSize":50,"DeleteOnTermination":true}},
{"DeviceName":"/dev/sdf","Ebs":{"VolumeType":"io2","VolumeSize":200,"Iops":10000,"DeleteOnTermination":false}}
]'
# Check whether an instance type includes instance store volumes
aws ec2 describe-instance-types \
--instance-types i4i.xlarge \
--query 'InstanceTypes[0].InstanceStorageInfo'Choosing the Right Fit
Reach for EBS for anything that must outlive the instance: databases, application root volumes, or any data you cannot afford to regenerate — gp3 is the sensible default for most workloads, with io2 Block Express reserved for latency-sensitive, high-IOPS databases. Reach for instance store when the workload is a cache that can be rebuilt (like a Redis or Memcached tier fronting a durable database), temporary scratch space for big data shuffling (Spark, Hadoop), or when a distributed system like Cassandra or a sharded search index already replicates data across multiple nodes, making per-node durability redundant.
Cricket analogy: It's like putting your primary XI's contracts (durable, must persist) in a proper HR system (EBS) while letting the substitute-fielder rotation for a single dead-rubber match (easily reset each game) live only in the day's team sheet (instance store).
You can take point-in-time, incremental snapshots of EBS volumes to S3 with 'aws ec2 create-snapshot', which is the standard way to back up EBS data and quickly recreate a volume in another AZ or Region. Instance store has no equivalent snapshot mechanism.
Stopping (not just rebooting) an EC2 instance that uses instance store volumes permanently destroys the data on those volumes, and the same happens if the underlying host hardware fails. Never treat instance store as a backup target or as the sole copy of anything you need to keep.
- EBS is network-attached, persistent block storage that survives instance stop/start and can move between instances.
- Instance store is physically attached to the host, offers very low latency and high IOPS, but is ephemeral.
- EBS volume types include gp3 (general purpose), io2 Block Express (highest IOPS), st1 (throughput HDD), and sc1 (cold HDD).
- Instance store data is lost on stop, terminate, or host failure, and only survives a reboot.
- Use EBS for anything that must persist: databases, root volumes, irreplaceable data.
- Use instance store for rebuildable caches, scratch space, or workloads with application-level replication.
- EBS supports point-in-time snapshots to S3; instance store has no built-in backup mechanism.
Practice what you learned
1. What happens to data on an EBS volume when its attached EC2 instance is stopped?
2. What happens to data on an instance store volume when the EC2 instance is stopped?
3. Which EBS volume type is designed for the highest IOPS, most latency-sensitive database workloads?
4. Which of these is a good candidate for instance store rather than EBS?
5. How can you back up the data on an EBS volume?
Was this page helpful?
You May Also Like
EFS Explained
Learn how Amazon EFS provides a fully managed, elastic NFS file system that multiple EC2 instances and containers can mount and share concurrently.
S3 Fundamentals
Learn how Amazon S3 stores data as objects in buckets, and the durability, consistency, and access-control model that makes it the backbone of AWS storage.
AWS Storage Gateway Overview
See how AWS Storage Gateway bridges on-premises applications to S3, EBS snapshots, and Glacier using File, Volume, and Tape gateway modes.