AWS EBS Volumes Explained: Types, Pricing & Use Cases

Simple explanation

An EBS volume is a persistent virtual hard drive for an EC2 instance. It lives in AWS’s storage infrastructure, connects to your instance over a high-speed network, and behaves exactly like a physical disk. You partition it, format it, mount it, read from it, and write to it.

The key word is persistent. When you shut down a physical computer, the hard drive keeps all your data. EBS works the same way. Stop your EC2 instance and the EBS volume stays exactly as you left it. Start the instance again and everything is still there.

How EBS works

Network-attached block storage

Unlike the physical SSD inside a laptop, EBS volumes live in AWS’s storage infrastructure and connect to your EC2 instance over a dedicated high-speed network. From the instance’s perspective, it looks like a local disk. Underneath, AWS handles replication, durability, and hardware failures automatically.

Same-AZ requirement

EBS volumes are tied to a specific Availability Zone. A volume in us-east-1a can only attach to instances running in us-east-1a. If you need to move a volume’s data to a different AZ, create a snapshot first, then restore it in the target AZ.

Root volumes and data volumes

When you launch an EC2 instance, it boots from a root volume: an EBS volume that holds the operating system. You can also attach additional data volumes to store application data, logs, or database files separately from the OS. Keeping data on a separate volume makes it easier to resize, replace, or recover individual components.

Persistence across stop and start

Stopping an EC2 instance does not touch its EBS volumes. All data is preserved. The root volume stays attached and reattaches automatically when the instance restarts. This is different from instance store volumes, which are physically local to the host and wiped when the instance stops.

Detach and reattach

EBS volumes exist independently of any particular EC2 instance. You can detach a volume from one instance, attach it to a different instance in the same AZ, and read the same data. This is useful for migrating data between instances, recovering a broken system, or cloning a disk for troubleshooting.

Snapshots as the backup path

The standard backup mechanism for EBS is EBS snapshots. A snapshot captures the state of a volume at a point in time and stores it in S3. Snapshots are incremental: only changed blocks are stored after the first one, so they are cost-efficient. You can restore a volume from a snapshot in any AZ within the same region, or copy it to another region for disaster recovery.

When to use EBS

EBS is the right storage choice in the following situations:

• EC2 boot volumes. Every EC2 instance launched from an AMI uses an EBS root volume by default. This is the most common EBS use case.
• Relational databases on EC2. MySQL, PostgreSQL, Oracle, and SQL Server all need fast, consistent block storage with low latency. EBS with gp3 or io2 provides this.
• App servers with local state. Applications that write session data, cache files, or temporary state to disk benefit from EBS’s predictable performance.
• Persistent data disks for EC2 workloads. Any data that needs to outlive the lifecycle of a particular instance (logs, uploads, generated files) belongs on a persistent EBS volume rather than instance store.
• Workloads needing low-latency block access. EBS delivers single-digit millisecond latency for SSD volume types, which is appropriate for most transactional workloads.

If you are launching your first EC2 instance, the default 8 GB gp3 root volume is a reasonable starting point for most purposes.

When not to use EBS

EBS is the wrong tool in some situations:

• Object storage. If you are storing static files, media, backups, or data lake content that does not need to be mounted as a filesystem, use S3. S3 is cheaper per GB and scales without pre-provisioning.
• Shared file access across multiple instances. EBS attaches to one instance at a time. If multiple instances need concurrent access to the same files over NFS, use EFS. See the S3 vs EFS comparison for guidance on choosing between object and file storage.
• Ephemeral scratch space. For temporary high-speed scratch data (caches, buffers, intermediate computation), instance store volumes are faster because they are physically attached to the host. If you do not need the data to persist, instance store avoids the EBS network overhead.
• Long-term cold archives. S3 Glacier is significantly cheaper than EBS for data you rarely access. Do not pay for provisioned EBS storage to hold data that only needs to be retrieved occasionally.

EBS vs other storage options

AWS offers several storage services with different trade-offs. Here is how EBS compares to the most common alternatives:

EBS vs instance store

Instance store is physically attached to the host server. It is faster than EBS for some workloads because there is no network in the path. The trade-off: instance store is ephemeral. When the instance stops or terminates, all data is gone. EBS persists independently. For most production workloads, EBS is the right choice because persistence matters more than the small latency advantage of local storage.

EBS vs EFS

EFS is a managed NFS filesystem that can be mounted by many EC2 instances simultaneously. EBS attaches to one instance at a time. If your workload needs a single instance with fast block storage, use EBS. If multiple instances need to read and write the same files concurrently, EFS is the appropriate choice, though at a higher cost per GB.

EBS vs S3

S3 is object storage, not block storage. You cannot mount S3 as a filesystem and have your application write to it like a disk. S3 uses an HTTP-based API for storing and retrieving objects. EBS works at the block level, so it is appropriate wherever a traditional disk is needed. S3 is significantly cheaper and scales without pre-provisioning, making it the better choice for blobs, backups, and static content.

EBS volume types

AWS offers two categories of EBS volumes: SSD-backed (optimised for IOPS) and HDD-backed (optimised for throughput at lower cost). Within each category there are current and previous-generation options.

gp3 (General Purpose SSD, current generation)

gp3 is the standard choice for most workloads. Unlike gp2, the baseline of 3,000 IOPS and 125 MB/s throughput is independent of volume size. A 1 GB gp3 volume gets the same baseline as a 16 TB volume. You can provision additional IOPS (up to 16,000) and throughput (up to 1,000 MB/s) independently, only paying for what you need. gp3 is approximately 20% cheaper than gp2.

Use gp3 for: boot volumes, most databases, web and app servers, development environments, and any workload that does not genuinely need more than 16,000 IOPS.

gp2 (General Purpose SSD, previous generation)

gp2 ties IOPS to volume size at 3 IOPS per GB, with a burst mechanism for smaller volumes. A 100 GB gp2 volume gets 300 baseline IOPS. To reach 3,000 IOPS on gp2, you needed a 1,000 GB volume, paying for unused space to hit a performance target. gp3 removed this limitation entirely. gp2 volumes are more expensive than equivalent gp3 configurations. Migrate existing gp2 volumes to gp3.

io2 and io2 Block Express (Provisioned IOPS SSD)

io2 is designed for I/O-intensive workloads that need consistent, high IOPS beyond what gp3 can provide: large relational databases running on EC2 (Oracle, SQL Server, large MySQL or PostgreSQL instances), SAP HANA, and other latency-sensitive workloads.

• io2: up to 64,000 IOPS and 1,000 MB/s throughput, 99.999% durability
• io2 Block Express: up to 256,000 IOPS and 4,000 MB/s throughput, sub-millisecond latency
• Multi-attach: io2 Block Express supports attaching to up to 16 instances simultaneously (same AZ, Linux, cluster-aware filesystem required)

io2 is significantly more expensive than gp3. Only use it when you have a measured, verified IOPS requirement that exceeds gp3’s 16,000 IOPS ceiling. Many teams over-provision io2 out of caution. It is worth benchmarking your workload on gp3 first.

io1 (Provisioned IOPS SSD, previous generation)

io1 is the predecessor to io2. io2 delivers higher durability (99.999% vs 99.8-99.9%) at the same price point. If you have io1 volumes, evaluate migrating to io2.

st1 (Throughput Optimised HDD)

st1 is designed for large sequential workloads where you read and write big blocks of data in order, not random access. It delivers up to 500 MB/s throughput at a much lower cost per GB than SSD volumes. It cannot be used as a boot volume.

Use st1 for: Hadoop/HDFS data nodes, Kafka log storage, video processing pipelines, data warehouse staging areas accessed sequentially. Minimum size is 125 GB.

sc1 (Cold HDD)

sc1 is the lowest-cost EBS option, designed for data that is accessed infrequently. It delivers up to 250 MB/s throughput at a lower price than st1, but it is not appropriate for workloads that need regular, fast access. It cannot be used as a boot volume. Minimum size is 125 GB.

Use sc1 for: cold archives, compliance data that must stay on block storage, infrequently accessed logs.

Which EBS volume type should I choose?

• Default to gp3. It is the right choice for the large majority of EC2 workloads: boot volumes, web servers, app servers, and most databases.
• Choose io2 only after measuring. If your database is genuinely bottlenecked on IOPS and gp3 at 16,000 IOPS is not enough, move to io2. Do not use io2 speculatively.
• Choose io2 Block Express for the most demanding databases. Oracle RAC, SAP HANA, or any workload requiring sub-millisecond latency or more than 64,000 IOPS.
• Choose st1 for large, sequential, cost-sensitive workloads. Hadoop clusters, Kafka, log aggregation, and streaming pipelines that read data sequentially benefit from st1’s throughput and lower cost.
• Choose sc1 only for rarely accessed data. If the data is accessed maybe once a month and cost is the primary driver, sc1 is appropriate. Otherwise st1 or gp3 will serve you better.
• Never create new gp2 or io1 volumes. These are legacy types. gp3 and io2 are better in every dimension at equal or lower cost.

Attaching, mounting, and resizing

The typical flow for adding an EBS data volume to a running instance: create it in the same AZ, attach it, format and mount it inside the instance, then make the mount persistent.

Create a 50 GB gp3 volume in the same AZ as your instance:

aws ec2 create-volume \
  --size 50 \
  --volume-type gp3 \
  --availability-zone us-east-1a \
  --tag-specifications 'ResourceType=volume,Tags=[{Key=Name,Value=my-data-volume}]'

Wait for the volume to become available, then attach it:

aws ec2 wait volume-available --volume-ids vol-0abc12345def67890

aws ec2 attach-volume \
  --volume-id vol-0abc12345def67890 \
  --instance-id i-0abc12345def67890 \
  --device /dev/sdf

Inside the instance, format and mount the new volume:

# Confirm the device name
lsblk

# Format with ext4 (only on a new, empty volume)
sudo mkfs -t ext4 /dev/nvme1n1

# Create the mount point and mount
sudo mkdir /data
sudo mount /dev/nvme1n1 /data

# Verify
df -h /data

To make the mount persist across reboots, add it to /etc/fstab using the UUID rather than the device name:

# Get the UUID
sudo blkid /dev/nvme1n1

# Add to /etc/fstab (replace <your-uuid> with the UUID from blkid)
echo 'UUID=<your-uuid> /data ext4 defaults,nofail 0 2' | sudo tee -a /etc/fstab

To detach a volume (it must be unmounted first):

# Inside the instance
sudo umount /data

# Via the CLI
aws ec2 detach-volume --volume-id vol-0abc12345def67890

Resizing a volume without downtime

EBS Elastic Volumes lets you increase a volume’s size, change its type, or adjust provisioned IOPS while it is attached to a running instance. No reboot required.

# Increase size from 50 GB to 100 GB
aws ec2 modify-volume \
  --volume-id vol-0abc12345def67890 \
  --size 100

# Or change type from gp2 to gp3 live
aws ec2 modify-volume \
  --volume-id vol-0abc12345def67890 \
  --volume-type gp3

After the volume modification completes, extend the filesystem inside the instance. The volume is larger, but the filesystem does not know that yet.

# Grow the partition (if the volume has a partition table)
sudo growpart /dev/nvme1n1 1

# Extend the ext4 filesystem to fill the new space
sudo resize2fs /dev/nvme1n1p1

EBS pricing

EBS pricing has several components and they vary by region and volume type. Check the AWS EBS pricing page for current figures in your region. The model works as follows:

• Storage (per GB-month): The base charge for provisioned capacity. gp3 is cheaper than gp2 per GB. HDD volumes (st1, sc1) are cheaper than SSD per GB. io2 charges more per GB than gp3.
• Provisioned IOPS: For gp3, the first 3,000 IOPS are included in the storage price. Additional provisioned IOPS cost extra. For io2, all provisioned IOPS are charged. For st1 and sc1, there is no separate IOPS charge.
• Throughput (gp3 only): The first 125 MB/s is included. Additional provisioned throughput up to 1,000 MB/s costs extra.
• Snapshots: Stored in S3 and billed separately at a per GB-month rate. Snapshots are incremental after the first, so ongoing costs are typically well below the full volume size. See the EBS snapshots guide for details.

Common EBS cost mistakes

• Orphaned unattached volumes. When you terminate an EC2 instance, its additional data volumes are not deleted by default. They remain as unattached volumes accumulating charges. Audit for unattached volumes regularly. The cleaning up unused resources guide covers this.
• Overprovisioned io2. io2 with provisioned IOPS is expensive. If you provisioned for peak load and the workload is consistently well below that ceiling, you are paying for unused performance. Measure actual IOPS and right-size accordingly.
• Not migrating gp2 to gp3. gp2 costs more per GB than gp3 and delivers worse performance at small sizes. There is no downside to migrating. This is one of the easiest wins in EC2 cost optimisation.
• Snapshot sprawl. If you run automated snapshots without a retention policy, old snapshots accumulate indefinitely. Use EBS snapshot lifecycle policies to expire old snapshots automatically.