03 / 11

Discuss EBS volume types.

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.

SSD-Backed — General Purpose: gp2 (Legacy)
  1. 1

    Full Name: General Purpose SSD v2

  2. 2

    Size: 1 GiB – 16 TiB

  3. 3

    Baseline IOPS: 3 IOPS per GiB (minimum 100, maximum 16,000 IOPS)

  4. 4

    Throughput: Up to 250 MiB/s

  5. 5

    Burst: Volumes under 1 TiB can burst to 3,000 IOPS using burst credits

  6. 6

    Use Cases: Boot volumes, small-to-medium databases, development environments

  7. 7

    Note: gp3 is newer, cheaper, and better — AWS recommends migrating from gp2 to gp3

SSD-Backed — General Purpose: gp3 (Recommended)
  1. 1

    Full Name: General Purpose SSD v3

  2. 2

    Size: 1 GiB – 16 TiB

  3. 3

    Baseline IOPS: 3,000 IOPS included at no extra cost (regardless of volume size)

  4. 4

    Maximum IOPS: Up to 16,000 IOPS (provisioned independently of size)

  5. 5

    Throughput: 125 MiB/s baseline, up to 1,000 MiB/s (provisioned independently)

  6. 6

    Cost: 20% cheaper per GiB than gp2

  7. 7

    Use Cases: Boot volumes, virtual desktops, medium databases, dev/test environments

  8. 8

    Key Advantage: IOPS and throughput are configurable independently of storage size — unlike gp2

SSD-Backed — Provisioned IOPS: io1
  1. 1

    Full Name: Provisioned IOPS SSD v1

  2. 2

    Size: 4 GiB – 16 TiB

  3. 3

    Maximum IOPS: Up to 64,000 IOPS (on Nitro-based instances)

  4. 4

    Maximum Throughput: 1,000 MiB/s

  5. 5

    IOPS-to-GiB Ratio: Maximum 50:1 (e.g., 16,000 IOPS requires at least 320 GiB)

  6. 6

    Multi-Attach: Supported — attach to up to 16 Nitro-based instances simultaneously

  7. 7

    Use Cases: I/O-intensive databases (MySQL, PostgreSQL, SQL Server, MongoDB), latency-sensitive production workloads

  8. 8

    Note: io2 is the newer, more durable successor to io1

SSD-Backed — Provisioned IOPS: io2 and io2 Block Express
  1. 1

    Full Name: Provisioned IOPS SSD v2

  2. 2

    Size: 4 GiB – 64 TiB (io2 Block Express)

  3. 3

    Maximum IOPS: 64,000 IOPS (io2), up to 256,000 IOPS (io2 Block Express)

  4. 4

    Maximum Throughput: 4,000 MiB/s (io2 Block Express)

  5. 5

    Durability: 99.999% (five nines) vs 99.8–99.9% for io1 and gp-series

  6. 6

    IOPS-to-GiB Ratio: Maximum 500:1 (10x better than io1)

  7. 7

    Multi-Attach: Supported

  8. 8

    Use Cases: Mission-critical databases, SAP HANA, large-scale Oracle/SQL Server, financial systems

  9. 9

    Note: io2 Block Express is the highest-performance EBS volume available

HDD-Backed — Throughput Optimized: st1
  1. 1

    Full Name: Throughput Optimized HDD

  2. 2

    Size: 125 GiB – 16 TiB

  3. 3

    Maximum Throughput: 500 MiB/s

  4. 4

    Maximum IOPS: 500 IOPS (not suitable for random I/O)

  5. 5

    Cost: Much cheaper per GiB than SSD volumes

  6. 6

    Cannot be used as a boot volume

  7. 7

    Use Cases: Big data (Hadoop, Spark), data warehouses, log processing, ETL pipelines, streaming workloads with large sequential reads

HDD-Backed — Cold HDD: sc1
  1. 1

    Full Name: Cold HDD

  2. 2

    Size: 125 GiB – 16 TiB

  3. 3

    Maximum Throughput: 250 MiB/s

  4. 4

    Maximum IOPS: 250 IOPS

  5. 5

    Cost: The lowest-cost EBS volume type

  6. 6

    Cannot be used as a boot volume

  7. 7

    Use Cases: Infrequently accessed cold data, archival storage, backups, disaster recovery data that rarely needs to be read

EBS Volume Types Quick Comparison
Difficulty: 5/10
Topics: volume types, performance, cost

Scenario Questions

0-2 years experience
  1. 1

    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.

  2. 2

    If you provision a magnetic (standard) EBS volume for a database and notice high latency, what would you change and why?

  3. 3

    What happens if you try to increase the size of a gp2 volume while it’s attached? Explain the process.

2-5 years experience
  1. 1

    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?

  2. 2

    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.

  3. 3

    During a backup window, snapshots of gp2 volumes are taking longer than expected. What factors could be causing this and how would you mitigate?

5-8 years experience
  1. 1

    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?

  2. 2

    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?

  3. 3

    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.

8+ years experience
  1. 1

    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.

  2. 2

    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?

  3. 3

    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?

Follow-up Questions

  • What metrics would you set up to monitor after changing the volume type?
  • How would you handle a situation where performance still falls short of the SLA?
  • Can you describe the cost‑impact analysis you’d perform before switching types?