This chapter covers Amazon Elastic Block Store (EBS) volume types, a core component of AWS compute services. Understanding EBS volume types is essential for the CLF-C02 exam, as it tests your ability to choose the right storage for EC2 instances based on performance and cost. This objective falls under Domain 3: Cloud Technology Services, which carries approximately 20% of the exam weight. You will learn the differences between SSD and HDD volumes, their use cases, and how to select the appropriate type for various workloads.
Jump to a section
Imagine you run a busy library. Your library has many bookshelves (EC2 instances) where patrons read books. But the books themselves are stored in a separate, secure room (EBS). Each bookshelf is connected to the book room via a dedicated tunnel (EBS volume attachment). When a patron wants a book, the librarian (AWS) retrieves it from the secure room and brings it to the bookshelf. The book room contains different types of shelves: some are made of solid oak (SSD) for fast access to frequently requested books, others are standard metal shelves (HDD) for slower, bulk storage of old newspapers. You can choose the shelf type based on how quickly patrons need the books. If you need the fastest access for bestsellers, you pick the oak shelf (io2/io1). For general reading, you pick a good quality oak shelf (gp3/gp2). For rarely accessed archives, you pick the metal shelf (st1/sc1). You can also increase the size of a shelf (resize volume) or move books to a different shelf (migrate volume type) without closing the library. The library charges you for the shelf space you reserve, even if no books are on it (provisioned capacity). And if a patron spills coffee on a book, you can restore it from a backup copy (snapshot) stored in a fireproof vault (Amazon S3).
What is Amazon EBS and the Problem It Solves
Amazon Elastic Block Store (EBS) provides persistent block-level storage volumes for use with Amazon EC2 instances. Unlike instance store volumes, which are ephemeral and lost when the instance stops, EBS volumes persist independently of the instance. This means you can stop and start an instance without losing data, or even detach a volume and attach it to another instance. EBS solves the problem of needing durable, high-performance, and scalable storage that can be dynamically attached to compute resources in the cloud.
How EBS Works
When you launch an EC2 instance, you can attach one or more EBS volumes. Each volume is provisioned in a specific Availability Zone (AZ) and can only be attached to instances in the same AZ. The volume appears as a raw, unformatted block device that you can partition and format with a file system (e.g., ext4, XFS). AWS replicates the volume within the AZ to protect against hardware failure. You can create point-in-time snapshots of volumes, which are stored in Amazon S3 and can be used to restore volumes in any AZ. Snapshots are incremental, meaning only changed blocks are saved, reducing storage costs.
EBS Volume Types
EBS offers two main categories: SSD-backed (solid-state drives) and HDD-backed (hard disk drives). SSD volumes are optimized for transactional workloads with frequent read/write operations and small I/O sizes. HDD volumes are optimized for large streaming workloads with sequential I/O. Within each category, there are further types:
#### SSD Volumes - io2 Block Express: The highest performance SSD volume, designed for business-critical, high-throughput, and low-latency workloads. It offers 99.999% durability and can scale up to 64 TiB with 256,000 IOPS and 4,000 MB/s throughput per volume. Use cases: large databases (Oracle, SQL Server), SAP HANA, and latency-sensitive applications. - io1: Previous generation high-performance SSD. Provides up to 64 TiB, 64,000 IOPS, and 1,000 MB/s throughput. io2 Block Express is recommended over io1 for new deployments. - gp3: General-purpose SSD that balances price and performance. Baseline performance is 3,000 IOPS and 125 MB/s for any volume size, with the ability to provision up to 16,000 IOPS and 1,000 MB/s independently of volume size. gp3 is cost-effective for most workloads. - gp2: Previous generation general-purpose SSD. Performance scales with volume size: baseline 3 IOPS/GiB, burstable to 3,000 IOPS for volumes up to 1 TiB. gp3 is recommended over gp2 due to better pricing and independent performance scaling.
#### HDD Volumes - st1 (Throughput Optimized HDD): Low-cost HDD designed for frequently accessed, throughput-intensive workloads. Baseline throughput is 40 MB/s per TiB (up to 500 MB/s per volume), burstable to 250 MB/s per TiB. Max volume size is 16 TiB. Use cases: big data, data warehouses, log processing. - sc1 (Cold HDD): Lowest cost HDD for less frequently accessed data. Baseline throughput is 12 MB/s per TiB (up to 250 MB/s per volume), burstable to 80 MB/s per TiB. Max volume size is 16 TiB. Use cases: colder data requiring fewer scans per day.
Note: HDD volumes cannot be used as boot volumes for EC2 instances. Only SSD volumes (gp2, gp3, io1, io2) can serve as root volumes.
Performance Characteristics
IOPS: Input/output operations per second. For SSD, io2 Block Express offers up to 256,000 IOPS, gp3 up to 16,000 IOPS. For HDD, IOPS is not the primary metric; throughput is.
Throughput: Measured in MB/s. HDD volumes are optimized for throughput: st1 up to 500 MB/s, sc1 up to 250 MB/s.
Volume Size: Ranges from 1 GiB to 64 TiB for SSD, up to 16 TiB for HDD.
Durability: EBS volumes have an annual failure rate (AFR) of 0.1% to 0.2%, meaning 99.8% to 99.9% durability. io2 Block Express offers 99.999% durability.
Pricing Model
You pay for the provisioned capacity (GB per month) and optionally for provisioned IOPS (for io1/io2) or provisioned throughput (for gp3). Snapshots incur storage costs in S3, and data transfer costs apply when copying snapshots across regions.
Comparison to On-Premises
On-premises, you would purchase physical storage arrays with fixed capacity and performance. Scaling requires hardware procurement and installation. With EBS, you can provision volumes in minutes, change volume types, and resize on the fly without downtime. Snapshots provide disaster recovery without managing backup tapes.
When to Use Each Type
io2 Block Express: Mission-critical databases requiring high IOPS and durability.
io1: Legacy applications that require provisioned IOPS but don't need the highest performance.
gp3: Default choice for most workloads: boot volumes, dev/test, small to medium databases.
gp2: Migrate to gp3 for cost savings and better performance.
st1: Big data, data warehousing, ETL workloads with large sequential reads/writes.
sc1: Infrequently accessed data, such as archive logs or backups that need to be online but accessed rarely.
Identify Workload Requirements
First, determine the I/O characteristics of your application. What is the average I/O size? Is it random or sequential? What are the peak IOPS and throughput requirements? For example, an online transaction processing (OLTP) database like MySQL performs many small random reads/writes, requiring high IOPS. A video streaming server reads large files sequentially, requiring high throughput. This step is critical because choosing the wrong volume type leads to either poor performance or overspending.
Select Volume Type
Based on requirements, choose the appropriate EBS volume type. For boot volumes and most applications, gp3 is recommended. For high-performance databases, choose io2 Block Express. For big data analytics with sequential access, choose st1. For rarely accessed data, choose sc1. Remember: HDD volumes cannot be boot volumes. Also consider that gp3 allows you to provision IOPS and throughput independently from storage size, which can be more cost-effective than gp2.
Provision Volume via Console or CLI
Create the volume in the AWS Management Console, AWS CLI, or via Infrastructure as Code (CloudFormation/Terraform). Specify the volume type, size (in GiB), and if applicable, provisioned IOPS and throughput. For example, using AWS CLI: `aws ec2 create-volume --volume-type gp3 --size 100 --iops 5000 --throughput 250 --availability-zone us-east-1a`. The volume is created in the specified AZ and remains available until attached.
Attach Volume to EC2 Instance
Attach the volume to an EC2 instance in the same AZ. You can attach up to 256 volumes to a Nitro-based instance (or up to 128 for previous generations). Use the console or CLI: `aws ec2 attach-volume --volume-id vol-1234567890abcdef0 --instance-id i-1234567890abcdef0 --device /dev/sdf`. The volume is exposed as a block device. Note that the device name may be renamed by the OS (e.g., /dev/nvme1n1 on Nitro instances).
Format and Mount the Volume
Once attached, you must format the volume with a file system (if new) and mount it. For example, on Linux: `sudo mkfs -t ext4 /dev/nvme1n1`, then `sudo mount /dev/nvme1n1 /mnt/data`. To make the mount persistent across reboots, add an entry to /etc/fstab. For Windows, you use Disk Management to initialize and format the volume. This step is identical to managing a physical disk.
Scenario 1: E-commerce Database Migration
A company runs an e-commerce platform on-premises using Oracle Database for order processing. They migrate to AWS, launching an EC2 instance (r5.8xlarge) in us-east-1a. For the database, they choose io2 Block Express volumes with 50,000 provisioned IOPS and 2,000 MB/s throughput. This ensures sub-millisecond latency for transaction processing. They set up Multi-AZ deployment by taking a snapshot of the primary volume and restoring it in us-east-1b, attaching it to a standby instance. Cost: ~$0.125/GB-month for storage plus $0.065 per provisioned IOPS-month. The total monthly cost for a 2 TB volume with 50,000 IOPS is approximately $3,500. If they had chosen gp3 with max IOPS (16,000), they would save 68% but risk performance degradation during peak sales.
Scenario 2: Big Data Log Processing
A media company processes terabytes of server logs daily using Apache Spark on a cluster of EC2 instances (i3en.6xlarge). They need high-throughput sequential read/write for intermediate data. They attach st1 volumes (1 TB each) to each instance, achieving 500 MB/s throughput per volume. The baseline throughput of 40 MB/s per TiB is sufficient for steady-state processing, but they benefit from bursting up to 250 MB/s per TiB for short periods. Cost: $0.045/GB-month, so 1 TB costs $45/month per instance. Misconfiguration: If they had used gp3, they would pay $0.08/GB-month ($80) and get only 125 MB/s baseline throughput, causing the Spark jobs to run 4x slower, increasing compute costs.
Scenario 3: Cold Storage for Compliance
A healthcare provider retains patient records for 10 years as required by HIPAA. They store the data on sc1 volumes attached to a single EC2 instance that is started once a month for audits. The data is accessed sequentially. sc1 costs $0.015/GB-month ($15 per TB). If they used gp3, it would cost $80 per TB, and they would pay for unused IOPS. However, they must be careful: sc1 volumes have a maximum throughput of 250 MB/s per volume, which may be insufficient if they need to restore large datasets quickly. A better approach might be to use S3 Glacier Deep Archive for $0.001/GB-month, but the exam focuses on EBS use cases.
What CLF-C02 Tests on This Objective
The exam tests your ability to differentiate between EBS volume types and choose the correct one for a given scenario. Specifically, you must know:
The two categories: SSD (gp2, gp3, io1, io2) and HDD (st1, sc1).
That only SSD volumes can be boot volumes.
That gp3 is the recommended general-purpose volume (not gp2).
That io2 Block Express offers the highest durability (99.999%) and IOPS (256,000).
That st1 is for throughput-intensive workloads, sc1 for cold data.
That HDD volumes are measured by throughput, not IOPS.
Common Wrong Answers and Why
Choosing gp2 over gp3: Candidates often select gp2 because it's familiar, but gp3 is newer, cheaper, and offers independent IOPS/throughput scaling. The exam expects you to know that gp3 is the default recommendation.
Using st1 as a boot volume: The exam may describe a scenario requiring a boot volume for a high-throughput workload. Candidates mistakenly choose st1 because it's throughput-optimized, but HDD volumes cannot be boot volumes. The correct answer is gp3.
Confusing IOPS and throughput: A question might ask which volume type is best for a database with many small random reads. Some candidates choose st1 because they think 'throughput' is needed, but the correct answer is an SSD volume (gp3 or io2) because random I/O requires high IOPS.
Assuming all volumes can be resized without downtime: While you can modify volume size, type, and IOPS online, some modifications (like changing from gp2 to io1) may require the volume to be detached and reattached. The exam may test that most modifications are live, but not all.
Specific Terms and Values on the Exam
gp3: up to 16,000 IOPS, 1,000 MB/s throughput, $0.08/GB-month.
io2 Block Express: up to 256,000 IOPS, 4,000 MB/s throughput, 99.999% durability.
st1: up to 500 MB/s throughput per volume, burst up to 250 MB/s per TiB.
sc1: up to 250 MB/s throughput per volume, burst up to 80 MB/s per TiB.
Maximum volume size: 64 TiB for SSD, 16 TiB for HDD.
Decision Rule for Multiple Choice
When a question asks 'Which EBS volume type should you use?', follow this elimination strategy: 1. Is it a boot volume? → Eliminate HDD (st1, sc1). 2. Is the workload random I/O (database, transactional)? → Choose SSD (gp3, io2). 3. Is the workload sequential I/O (big data, streaming)? → Choose HDD (st1 for frequent, sc1 for cold). 4. Does it require very high IOPS (>16,000) or durability (>99.9%)? → Choose io2 Block Express. 5. Otherwise, default to gp3.
EBS provides persistent block storage for EC2, replicated within a single AZ.
Only SSD volumes (gp2, gp3, io1, io2) can be boot volumes.
gp3 is the recommended general-purpose SSD, with baseline 3000 IOPS and 125 MB/s.
io2 Block Express offers up to 256,000 IOPS and 99.999% durability.
st1 is for throughput-intensive sequential workloads; sc1 for cold data.
HDD volumes are measured by throughput, not IOPS.
EBS snapshots are stored in S3 and are incremental.
Maximum volume size is 64 TiB for SSD, 16 TiB for HDD.
These come up on the exam all the time. Here's how to tell them apart.
gp2
Baseline 3 IOPS/GiB, burst to 3000 IOPS
Max 16,000 IOPS (only for volumes > 5.33 TiB)
Max throughput 250 MB/s (only for volumes > 1 TiB)
Cost: $0.10/GB-month
Performance tied to volume size
gp3
Baseline 3000 IOPS and 125 MB/s for any size
Max 16,000 IOPS (provisionable independently)
Max throughput 1000 MB/s (provisionable independently)
Cost: $0.08/GB-month
Performance independent of volume size
st1
Throughput Optimized HDD
Baseline 40 MB/s per TiB (up to 500 MB/s)
Burst 250 MB/s per TiB
$0.045/GB-month
Frequently accessed data
sc1
Cold HDD
Baseline 12 MB/s per TiB (up to 250 MB/s)
Burst 80 MB/s per TiB
$0.015/GB-month
Infrequently accessed data
Mistake
EBS volumes are automatically replicated across multiple Availability Zones.
Correct
EBS volumes are replicated within a single Availability Zone only. To protect against AZ failures, you must take snapshots and restore in another AZ, or use services like EBS Multi-Attach or replication with other services.
Mistake
HDD volumes (st1/sc1) can be used as boot volumes.
Correct
Only SSD-backed volumes (gp2, gp3, io1, io2) can serve as boot volumes for EC2 instances. HDD volumes are data volumes only.
Mistake
gp2 and gp3 provide the same performance for the same price.
Correct
gp3 offers better price-performance. gp2 performance scales with size (3 IOPS/GiB), while gp3 has baseline performance independent of size and allows separate provisioning of IOPS and throughput. gp3 is generally cheaper for most workloads.
Mistake
EBS snapshots are stored in EBS.
Correct
EBS snapshots are stored in Amazon S3, not in EBS. They are incremental and compressed, reducing storage costs.
Mistake
You can attach an EBS volume to instances in different Availability Zones.
Correct
EBS volumes are AZ-specific. They can only be attached to instances in the same Availability Zone. To use a volume in another AZ, you must create a snapshot and restore it in the target AZ.
EBS provides persistent block storage that survives instance stop/termination, while instance store is ephemeral storage physically attached to the host. Instance store data is lost when the instance is stopped or terminated. EBS volumes can be detached and reattached, snapshotted, and resized. Instance store offers higher IOPS but no durability. On the exam, know that EBS is for persistent data, instance store for temporary data.
Yes, you can modify the volume type, size, and IOPS/throughput without downtime using the ModifyVolume API. For example, you can change a gp2 volume to gp3, or increase IOPS on an io1 volume. However, some modifications (e.g., changing from gp2 to io1) may require the instance to be rebooted if the device is attached. The exam may test that most modifications are live.
gp3 can achieve up to 16,000 IOPS (provisioned) and 1,000 MB/s throughput. The baseline is 3,000 IOPS and 125 MB/s for any volume size. You can provision additional IOPS and throughput independently at extra cost. This is a common exam value.
Boot volumes require the ability to handle many small random I/O operations (loading OS files, drivers). HDD volumes are optimized for sequential throughput, not random IOPS. SSD volumes provide the low latency and high IOPS needed for OS boot. The exam explicitly states that HDD volumes cannot be boot volumes.
EBS snapshots are point-in-time copies stored in Amazon S3. The first snapshot is a full copy; subsequent snapshots are incremental, saving only changed blocks. You can create snapshots while the volume is attached (with or without application consistency). Snapshots can be used to restore volumes in any AZ, create AMIs, or migrate data across regions. The exam may ask about incremental nature.
io2 Block Express is the newer generation, offering higher durability (99.999% vs 99.9%), higher IOPS (256,000 vs 64,000), and higher throughput (4,000 MB/s vs 1,000 MB/s). io2 is recommended for new deployments. The exam may refer to io2 as the high-performance option.
Yes, you can attach multiple volumes, up to the instance's volume limit (e.g., 256 for Nitro-based instances). Each volume can be different types. You can also use logical volume management (LVM) to combine them. This is common for databases that need separate volumes for data, logs, and backups.
You've just covered Amazon EBS Volume Types — now see how well it sticks with free CLF-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?