Amazon EBS Explained: Volume Types, Snapshots, Performance, and Best Practices

Amazon EBS is the block storage layer most EC2-backed systems depend on, so the wrong volume choice can quietly waste money or slow a database under load. The practical rule is simple. Start with gp3. Move to io2 only when the workload proves it needs guaranteed high IOPS or higher durability, and use st1 or sc1 when the access pattern is large and sequential.

If you build on AWS, you will see EBS behind Linux boot disks, SQL Server data files, Kubernetes persistent volumes, analytics nodes, and disaster recovery workflows. The details matter. A 200 GiB gp2 volume behaves very differently from a 200 GiB gp3 volume, even though both carry the General Purpose SSD label.

What Is Amazon EBS?

Amazon Elastic Block Store, usually called Amazon EBS, provides persistent block storage for Amazon EC2 instances. It acts like a network-attached disk at the operating system level. You format it with ext4, XFS, NTFS, or another filesystem, mount it, and applications read and write blocks.

EBS volumes live in a single Availability Zone. You can detach a volume from one EC2 instance and attach it to another compatible instance in the same Availability Zone. For backups and migration, you use EBS snapshots, which are point-in-time copies stored by AWS and used to create new volumes later.

EBS Volume Types: The Current Choices

AWS groups EBS volume types into SSD-backed and HDD-backed families. SSD volumes are built for smaller random I/O where IOPS and latency matter. HDD volumes are built for larger sequential transfer where throughput is the main metric.

gp3: The Default Choice for Most Workloads

gp3 is the current General Purpose SSD volume type and should be your first option for most new workloads. AWS documentation states that gp3 provides 3,000 baseline IOPS and 125 MiB/s throughput at any volume size. You can provision performance separately from capacity, up to 64 TiB, 16,000 IOPS, and 1,000 MiB/s per volume.

That separation is the big change. With gp2, you often had to buy more GiB just to get more IOPS. With gp3, a small volume can still be fast if you provision extra IOPS or throughput. In real cost reviews, this is often the easiest storage saving to find. Migrate idle or oversized gp2 volumes to gp3, then right-size the performance settings.

Use gp3 for:

• EC2 boot volumes
• Web and API servers
• Development and test environments
• Virtual desktops
• Small to mid-sized MySQL, PostgreSQL, Oracle, or SQL Server databases

gp2: Common, But Mostly Legacy

gp2 is still everywhere because it was the old default. Its performance scales with size at 3 IOPS per GiB, up to 16,000 IOPS. Volumes smaller than 1 TiB can burst to 3,000 IOPS using credits.

That credit model bites beginners. I have seen a small gp2 database look fine during testing, then stall during a reporting job after BurstBalance drained to zero in CloudWatch. On the instance, iostat -xz 1 showed await jumping from single-digit milliseconds to hundreds. Nothing was wrong with PostgreSQL. The disk had simply run out of burst credits.

For new deployments, choose gp3 unless you have a specific compatibility or migration reason to keep gp2.

io1, io2, and io2 Block Express

Provisioned IOPS SSD volumes are for workloads that need predictable high IOPS. AWS says io1, io2, and io2 Block Express are designed to deliver 90 percent of provisioned performance 99.9 percent of the year. General Purpose SSD volumes target 90 percent performance 99 percent of the year.

io2 also has a higher durability target: 99.999 percent durability, or about 0.001 percent annual failure rate. By comparison, gp2, gp3, and io1 are listed by AWS with an annual failure rate around 0.1 percent to 0.2 percent.

io2 Block Express is the top EBS tier, supporting up to 256,000 IOPS and 4,000 MiB/s per volume. It is the right fit for the largest OLTP databases, high-write NoSQL systems, financial workloads, and systems where storage latency has a direct business impact. It is not the right choice for a normal web server. To be blunt, many teams buy premium IOPS before fixing bad queries, missing indexes, or chatty application writes.

st1 and sc1: HDD Volumes Still Matter

st1, or Throughput Optimized HDD, is built for large sequential workloads. Think log processing, data warehouses, Hadoop-style workloads, and ETL jobs that scan big files.

sc1, or Cold HDD, is for infrequently accessed data. It fits long-term logs, historical datasets, and low-touch archival workloads where cost matters more than latency.

Do not use st1 or sc1 for boot volumes or transactional databases. Random I/O on HDD-backed EBS is the wrong tool for that job.

EBS Snapshots: Backups, Restores, and First-Read Latency

EBS snapshots are point-in-time backups of volumes. They are incremental at the block level, so after the first snapshot, AWS stores changed blocks rather than copying the entire volume again.

Snapshots are used for:

• Volume backups
• Disaster recovery
• Golden image workflows
• Copying data across Regions or accounts
• Creating test environments from production-like data

There is one performance detail you should not ignore. When you create a new EBS volume from a snapshot, blocks are loaded from Amazon S3-backed snapshot storage the first time they are read. AWS documentation warns that this first access can add noticeable latency.

You have two practical fixes:

1. Pre-initialize the volume. Read every block before production traffic hits it. On Linux, teams often use tools such as fio or dd carefully for this purpose.
2. Use Fast Snapshot Restore. FSR lets volumes created from selected snapshots deliver provisioned performance immediately, without waiting for first-read initialization.

For autoscaling fleets, disaster recovery drills, and database restore procedures, Fast Snapshot Restore can be worth the cost. For a one-off development restore, manual initialization is usually enough.

EBS Performance Metrics That Actually Matter

EBS performance comes down to three measurements:

• IOPS: Operations per second. Critical for databases and random reads or writes.
• Throughput: MiB/s transferred. Critical for scans, analytics, backups, and logs.
• Latency: Time per I/O operation. Critical for user-facing applications and transaction systems.

Volume settings are only half the story. The EC2 instance type also has EBS bandwidth limits. A high-end EBS volume attached to an underpowered instance will not reach its advertised limit. For high-performance io1 or io2 setups, AWS often requires Nitro-based instances to hit upper throughput levels.

Quick Troubleshooting Checklist

When an EBS-backed application is slow, check from the inside out:

• Run iostat -xz 1 to inspect utilization, queue size, read latency, and write latency.
• Use top or vmstat 1 to rule out CPU steal, memory pressure, and swapping.
• Compare CloudWatch volume metrics with provisioned IOPS and throughput.
• Check gp2 BurstBalance if the volume is still gp2.
• Confirm the EC2 instance has enough EBS bandwidth for the configured volume.
• Review filesystem choices, mount options, batching, indexes, and application write patterns.

For repeatable testing, fio is the standard tool. A simple read test might look like this:

fio --name=readtest --filename=/mnt/testfile --size=4G --rw=randread --bs=16k --iodepth=32 --numjobs=4 --runtime=60 --time_based --direct=1

Run tests on non-production volumes first. A careless write test against the wrong mount point can ruin your morning.

Best Practices for Amazon EBS Design

1. Start With gp3, Then Prove You Need More

For most systems, gp3 gives the best balance of cost and performance. Set capacity based on data needs, then tune IOPS and throughput based on measurements. This is cleaner than padding gp2 volume size just to gain baseline IOPS.

2. Reserve io2 for Critical Databases

Use io2 or io2 Block Express when you need sustained high IOPS, tighter performance consistency, and stronger durability. If your workload is a core banking database or a high-volume order system, that premium may be justified. If it is a staging API, it probably is not.

3. Match HDD Volumes to Sequential Workloads

Use st1 for big sequential reads and writes. AWS recommends maintaining a queue length of at least 4 for 1 MiB sequential I/O on HDD-backed volumes. For Linux, AWS also recommends setting read-ahead to 1 MiB for these workloads.

4. Treat Snapshots as Part of the Architecture

Set snapshot schedules, retention rules, and restore tests. A backup you have never restored is only a theory. For critical workloads, consider cross-Region snapshot copies and account-level separation for recovery from operator error or account compromise.

5. Monitor Cost and Idle Provisioning

Provisioned IOPS and throughput cost money. Review EBS usage monthly. Look for unattached volumes, old snapshots, overprovisioned gp3 settings, and gp2 volumes that can be migrated.

Where This Fits in AWS Skills Development

If you are preparing for cloud architecture, DevOps, or infrastructure engineering roles, Amazon EBS is not trivia. Certification candidates often remember the names of the volume types but miss the operating behavior: gp2 burst credits, gp3 independent provisioning, snapshot first-read latency, and the difference between IOPS-bound and throughput-bound systems.

As an internal learning path, pair this topic with Global Tech Council resources on cloud computing, DevOps automation, Linux administration, and cybersecurity fundamentals. Storage choices affect backup strategy, incident recovery, database performance, and cloud cost governance.

Final Takeaway

Choose gp3 for the default path, io2 or io2 Block Express for proven high-end database needs, st1 for sequential analytics and logs, and sc1 for cold data. Then test. Use CloudWatch, iostat, and restore drills before users discover the bottleneck for you.

Your next step: audit one EC2 workload today. Check its EBS volume type, IOPS, throughput, snapshot policy, and CloudWatch metrics. If it is still on gp2 without a reason, gp3 is the first change to evaluate.