Amazon EBS offers six volume types divided into two main categories: SSD-backed volumes (gp2, gp3, io1, io2) for transactional workloads requiring high IOPS, and HDD-backed volumes (st1, sc1) for sequential, throughput-intensive workloads. Each type differs in performance, cost, and use case.
Choosing the right EBS volume type is one of the most important cost and performance decisions in AWS architecture. SSD-based volumes are optimized for small, random I/O operations (databases, boot volumes), while HDD-based volumes are optimized for large, sequential I/O operations (big data, log processing). Only SSD types (gp2, gp3, io1, io2) can be used as boot/root volumes.
Full Name: General Purpose SSD v2
Size: 1 GiB – 16 TiB
Baseline IOPS: 3 IOPS per GiB (minimum 100, maximum 16,000 IOPS)
Throughput: Up to 250 MiB/s
Burst: Volumes under 1 TiB can burst to 3,000 IOPS using burst credits
Use Cases: Boot volumes, small-to-medium databases, development environments
Note: gp3 is newer, cheaper, and better — AWS recommends migrating from gp2 to gp3
Full Name: General Purpose SSD v3
Size: 1 GiB – 16 TiB
Baseline IOPS: 3,000 IOPS included at no extra cost (regardless of volume size)
Maximum IOPS: Up to 16,000 IOPS (provisioned independently of size)
Throughput: 125 MiB/s baseline, up to 1,000 MiB/s (provisioned independently)
Cost: 20% cheaper per GiB than gp2
Use Cases: Boot volumes, virtual desktops, medium databases, dev/test environments
Key Advantage: IOPS and throughput are configurable independently of storage size — unlike gp2
Full Name: Provisioned IOPS SSD v1
Size: 4 GiB – 16 TiB
Maximum IOPS: Up to 64,000 IOPS (on Nitro-based instances)
Maximum Throughput: 1,000 MiB/s
IOPS-to-GiB Ratio: Maximum 50:1 (e.g., 16,000 IOPS requires at least 320 GiB)
Multi-Attach: Supported — attach to up to 16 Nitro-based instances simultaneously
Use Cases: I/O-intensive databases (MySQL, PostgreSQL, SQL Server, MongoDB), latency-sensitive production workloads
Note: io2 is the newer, more durable successor to io1
Full Name: Provisioned IOPS SSD v2
Size: 4 GiB – 64 TiB (io2 Block Express)
Maximum IOPS: 64,000 IOPS (io2), up to 256,000 IOPS (io2 Block Express)
Maximum Throughput: 4,000 MiB/s (io2 Block Express)
Durability: 99.999% (five nines) vs 99.8–99.9% for io1 and gp-series
IOPS-to-GiB Ratio: Maximum 500:1 (10x better than io1)
Multi-Attach: Supported
Use Cases: Mission-critical databases, SAP HANA, large-scale Oracle/SQL Server, financial systems
Note: io2 Block Express is the highest-performance EBS volume available
Full Name: Throughput Optimized HDD
Size: 125 GiB – 16 TiB
Maximum Throughput: 500 MiB/s
Maximum IOPS: 500 IOPS (not suitable for random I/O)
Cost: Much cheaper per GiB than SSD volumes
Cannot be used as a boot volume
Use Cases: Big data (Hadoop, Spark), data warehouses, log processing, ETL pipelines, streaming workloads with large sequential reads
Full Name: Cold HDD
Size: 125 GiB – 16 TiB
Maximum Throughput: 250 MiB/s
Maximum IOPS: 250 IOPS
Cost: The lowest-cost EBS volume type
Cannot be used as a boot volume
Use Cases: Infrequently accessed cold data, archival storage, backups, disaster recovery data that rarely needs to be read
You need to attach a 100 GB gp3 volume to an EC2 instance for a web server. Walk me through the steps you’d take in the console and any parameters you’d set.
If you provision a magnetic (standard) EBS volume for a database and notice high latency, what would you change and why?
What happens if you try to increase the size of a gp2 volume while it’s attached? Explain the process.
Our application stores logs on an io2 volume but we’re hitting IOPS limits during peak traffic. How would you diagnose and decide whether to switch volume types or adjust settings?
We have a mixed workload: a MySQL database on gp3 and a cache layer on st1. A recent deployment caused the database to become I/O bound. Explain how you’d evaluate if the current volume type is appropriate and what changes you’d make.
During a backup window, snapshots of gp2 volumes are taking longer than expected. What factors could be causing this and how would you mitigate?
Design a storage strategy for a high‑throughput analytics pipeline that writes terabytes per hour, considering EBS volume types, cost, and durability. Which volumes would you choose for each component and why?
Our microservice architecture uses many short‑lived EC2 instances that need fast, temporary storage. How would you decide between using gp3, io2, or instance store, and what trade‑offs would you highlight?
We need to migrate a legacy application from magnetic volumes to a modern SSD‑based setup without downtime. Outline the migration plan, including data consistency and performance considerations.
At scale, our organization runs thousands of EC2 instances across multiple regions, each with different workload profiles. Propose a governance framework for selecting EBS volume types, managing cost, and ensuring compliance with performance SLAs.
We’re consolidating multiple legacy data stores onto a unified storage platform. How would you evaluate the long‑term trade‑offs of standard vs. gp3 vs. io2, factoring in future growth, backup strategy, and cross‑team ownership?
If a new AWS feature introduces a different pricing model for provisioned IOPS, how would you reassess existing io2 volumes across the fleet to optimize cost while maintaining required performance?