This chapter covers Amazon EBS performance characteristics, focusing on IOPS, throughput, and the io2 Block Express volume type. Understanding these concepts is essential for the SAA-C03 exam, as questions on EBS volume types and performance optimization appear in approximately 10-15% of exam questions. You will learn how IOPS and throughput interact, how different volume types deliver performance, and how to choose the right configuration for your workloads. Mastering these details will help you avoid common exam traps and design cost-effective, high-performance storage solutions.
Jump to a section
Think of an EBS volume as a building's plumbing system. IOPS (Input/Output Operations Per Second) is like the number of faucets you can turn on simultaneously — each faucet represents an I/O operation. Throughput (MB/s) is the total volume of water flowing through all faucets combined. The pipe diameter (volume size and type) determines the maximum flow rate. io2 Block Express is like upgrading from standard copper pipes to high-pressure industrial pipes — it allows many more faucets to run at full blast simultaneously without pressure drop. The burst bucket (for gp2/gp3) is like a water tank that fills over time; when you need a sudden surge (e.g., booting an OS), you can draw from the tank. But if you exceed the baseline refill rate, the tank empties and flow slows. Provisioned IOPS (io1/io2) is like paying for a guaranteed number of faucets always available — no tank, just a direct high-pressure line. The volume's queue depth is the number of partially filled buckets waiting at each faucet; too few buckets means the faucet runs dry (underutilized), too many means backups (latency). EBS-optimized instances provide dedicated plumbing to the EBS network, avoiding contention with other traffic. Understanding these mechanics is critical for choosing the right EBS volume type and avoiding performance bottlenecks.
What are IOPS and Throughput?
IOPS (Input/Output Operations Per Second) measures the number of read or write operations that a storage device can handle per second. Throughput (measured in MB/s or MiB/s) measures the amount of data transferred per second. They are related but distinct: IOPS determines how many operations you can do, while throughput determines how much data you can move. For small I/O sizes (e.g., 4 KiB), IOPS is the limiting factor; for large I/O sizes (e.g., 1 MiB), throughput becomes the limiting factor. The relationship is: Throughput = IOPS × I/O size.
EBS Volume Types and Performance
Amazon EBS offers several volume types with different performance profiles:
gp2: General Purpose SSD, baseline 3 IOPS/GiB, burst up to 3000 IOPS for volumes up to 1 TiB using a burst bucket. Max IOPS 16000, max throughput 250 MiB/s.
gp3: General Purpose SSD, baseline 3000 IOPS and 125 MiB/s regardless of size, can provision up to 16000 IOPS and 1000 MiB/s independently.
io1: Provisioned IOPS SSD, max 50 IOPS/GiB, up to 64000 IOPS per volume (nitro instances) or 32000 (previous gen), max throughput 1000 MiB/s.
io2: Provisioned IOPS SSD, max 500 IOPS/GiB, up to 64000 IOPS, max throughput 1000 MiB/s, 99.999% durability.
io2 Block Express: Provisioned IOPS SSD, max 1000 IOPS/GiB, up to 256000 IOPS, max throughput 4000 MiB/s, 99.999% durability, sub-millisecond latency.
st1: Throughput Optimized HDD, baseline 40 MiB/s per TB, burst up to 250 MiB/s per TB, max 500 MiB/s per volume.
sc1: Cold HDD, baseline 12 MiB/s per TB, burst up to 80 MiB/s per TB, max 250 MiB/s per volume.
How IOPS and Throughput are Delivered
Each EBS volume type has a defined maximum IOPS and throughput. For gp2, IOPS scales with volume size up to 16000 IOPS at 5.34 TiB. gp3 allows independent scaling of IOPS and throughput. io1 and io2 provision IOPS directly, with a minimum ratio of 1 IOPS per GiB for io1 and 0.5 IOPS per GiB for io2. io2 Block Express can provision up to 256000 IOPS and 4000 MiB/s, with a minimum ratio of 1 IOPS per GiB.
Burst Bucket Mechanism (gp2 and gp3)
gp2 volumes have a burst bucket that fills at the baseline rate (3 IOPS/GiB) and can burst to 3000 IOPS for volumes up to 1 TiB. The bucket size is 5.4 million I/O credits for gp2. For gp3, the baseline is 3000 IOPS and 125 MiB/s, and you can provision additional IOPS or throughput, but there is no burst bucket for gp3 beyond baseline.
Queue Depth and Latency
Queue depth (QD) is the number of pending I/O requests. To achieve maximum IOPS, you need sufficient QD to keep the device busy. For EBS, a QD of 1-2 is typically enough for low latency, but for high IOPS, you may need QD of 10-20 or more. The relationship between QD, IOPS, and latency can be described by Little's Law: QD = IOPS × latency.
EBS-Optimized Instances and EBS Bandwidth
EBS-optimized instances provide dedicated bandwidth to EBS, separate from network traffic. For example, a c5.2xlarge instance provides up to 4.5 Gbps EBS bandwidth. If you use a non-optimized instance (e.g., t2.micro), EBS traffic shares the network interface, leading to contention. The exam often tests that you must use an EBS-optimized instance to achieve maximum EBS performance.
io2 Block Express Deep Dive
io2 Block Express is the highest performance EBS volume type, designed for latency-sensitive workloads like databases (SAP HANA, Oracle). It uses a new architecture with a dedicated storage server and NVMe interface. Key features:
Up to 256000 IOPS per volume (64 TiB max size)
Up to 4000 MiB/s throughput
Sub-millisecond latency
99.999% durability (five nines)
Requires an instance that supports Block Express (e.g., R5b, M5dn, C5n, etc.)
The volume must be attached as an NVMe device.
Interplay with Instance Types
The instance type determines the maximum EBS bandwidth available. For example, an m5.large has up to 2.12 Gbps EBS bandwidth, while an m5.24xlarge has up to 19 Gbps. You cannot exceed the instance's EBS bandwidth, even if the volume can provide more. The exam often asks to identify the bottleneck when performance is lower than expected.
Monitoring and Verification
Use CloudWatch metrics to monitor EBS performance:
- VolumeReadOps / VolumeWriteOps: Number of read/write operations per minute.
- VolumeReadBytes / VolumeWriteBytes: Bytes read/written per minute.
- VolumeQueueLength: Number of pending I/O requests.
- VolumeIdleTime: Time with no I/O.
To verify IOPS and throughput, use tools like fio or dd on Linux. Example fio command:
fio --filename=/dev/xvdf --direct=1 --rw=randread --bs=4k --iodepth=256 --runtime=60 --numjobs=4 --time_based --group_reporting --name=testThis tests random read IOPS with 4 KiB blocks.
Interaction with Snapshots
Snapshots are incremental and capture data at the block level. While a snapshot is in progress, performance may be slightly impacted due to I/O amplification. The first snapshot is a full copy; subsequent snapshots only copy changed blocks. For volumes with high write rates, snapshot performance can degrade if the volume is busy.
Encryption and Performance
EBS encryption uses AES-256 and is handled by the Nitro chip. There is minimal performance overhead (less than 5%) for most workloads. However, for very high IOPS volumes, encryption may add latency. The exam does not test encryption performance in detail but may mention that encryption is transparent.
RAID Configurations
You can stripe multiple EBS volumes using RAID 0 to increase IOPS and throughput. For example, six io1 volumes at 10000 IOPS each can provide 60000 IOPS in RAID 0. However, RAID 0 increases risk of data loss; use RAID 1 for mirroring but at half the capacity. The exam may ask about RAID 0 for performance vs. RAID 1 for durability.
Key Defaults and Constraints
Minimum volume size: 1 GiB for gp2/gp3/io1/io2, 125 GiB for st1/sc1.
Maximum volume size: 16 TiB for gp2/gp3/io1/io2 (except io2 Block Express: 64 TiB), 16 TiB for st1/sc1.
IOPS limits per instance: varies by instance type, e.g., c5.24xlarge supports 60,000 IOPS (EBS-optimized).
Throughput limits per instance: e.g., c5.24xlarge supports 19 Gbps (2375 MiB/s).
Exam Relevance
The SAA-C03 exam tests your ability to choose the right EBS volume type based on performance requirements. You should know the difference between gp2 and gp3 (gp3 allows independent scaling), when to use io1 vs io2 (io2 has higher durability and IOPS/GiB), and when to use io2 Block Express (for extreme performance). Also understand burst bucket behavior for gp2 and the impact of instance EBS bandwidth.
Identify Performance Requirements
Determine the required IOPS and throughput for your workload. For example, a database may need 10000 IOPS with 4 KiB block size, leading to 40 MiB/s throughput. If your workload is throughput-intensive (e.g., video processing), focus on throughput rather than IOPS. Also consider latency sensitivity: sub-millisecond for transactional databases, tens of milliseconds for batch processing.
Choose EBS Volume Type
Based on requirements, select the appropriate volume type. For general-purpose workloads with moderate performance, gp3 is cost-effective. For high IOPS, choose io1 or io2. For extreme performance, use io2 Block Express. For large sequential data access, use st1. For cold data, use sc1. Consider cost: gp3 is cheaper than io1 for similar performance.
Configure Volume Size and Performance
For gp2, IOPS scales with size (3 IOPS/GiB). For gp3, set baseline IOPS (3000 default) and throughput (125 MiB/s default), then provision additional IOPS up to 16000 and throughput up to 1000 MiB/s. For io1/io2, provision IOPS directly (max 50 IOPS/GiB for io1, 500 for io2, 1000 for io2 Block Express). Ensure the volume size is at least the minimum required to support the provisioned IOPS (e.g., for io1, 1 GiB per IOPS).
Attach to EBS-Optimized Instance
Select an instance type that is EBS-optimized (most current generation instances are). Verify the instance's maximum EBS bandwidth and IOPS limits. For example, a c5.2xlarge has up to 4.5 Gbps EBS bandwidth and 20,000 IOPS. If you provision 30,000 IOPS on the volume, the instance will be the bottleneck. Use Nitro instances for better performance.
Set Appropriate Queue Depth
Configure the application or OS to use sufficient queue depth to achieve target IOPS. For high IOPS, use an I/O scheduler like 'noop' or 'none' on Linux, and increase the device queue depth (e.g., `echo 256 > /sys/block/xvdf/queue/nr_requests`). In applications, use asynchronous I/O or increase thread count. Monitor CloudWatch `VolumeQueueLength` to ensure it is not too high (indicating latency) or too low (underutilization).
Monitor and Optimize
Use CloudWatch metrics to monitor actual IOPS and throughput. Compare to provisioned values. If performance is lower than expected, check instance EBS bandwidth, queue depth, and network contention. Also check if the volume is throttled (e.g., gp2 burst bucket empty). Adjust volume type, size, or instance type as needed. Use Elastic Block Store Direct APIs for low-level monitoring.
Scenario 1: High-Performance Database (SAP HANA)
A financial services company runs SAP HANA on AWS. They require extremely low latency (sub-millisecond) and high IOPS (over 100,000) for transaction logs and data files. They choose io2 Block Express volumes attached to R5b instances (which support Block Express). Each volume is provisioned with 64 TiB size and 256,000 IOPS. They use RAID 0 across two volumes for even higher throughput. They monitor CloudWatch metrics to ensure queue depth stays between 10-20 to maintain latency. Misconfiguration: If they attach to an instance that does not support Block Express (e.g., m5.large), the volume will fall back to standard io2 performance (64,000 IOPS max). Common mistake: Not enabling EBS-optimized instance (but R5b is always EBS-optimized).
Scenario 2: Large-Scale Video Processing
A media company processes 4K video files, requiring high throughput (500 MiB/s) but moderate IOPS (5000). They choose gp3 volumes with provisioned throughput of 500 MiB/s and baseline 3000 IOPS (they need 5000 IOPS, so they provision additional 2000 IOPS). They attach to c5n.4xlarge instances which provide up to 4.75 Gbps EBS bandwidth (~600 MiB/s). They use sequential I/O with large block sizes (1 MiB) to maximize throughput. Misconfiguration: If they use gp2 instead of gp3, they would need a large volume (167 GiB) to get 500 IOPS baseline, but burst would only last for a limited time. Also, they might hit the gp2 burst bucket limit during long renders. They avoid this by using gp3 with consistent performance.
Scenario 3: Boot Volumes for EC2 Auto Scaling
An e-commerce company uses Auto Scaling groups with EC2 instances. Each instance has a 30 GiB gp3 boot volume. They need reasonable IOPS for OS boot and application startup. gp3 provides 3000 IOPS baseline and 125 MiB/s throughput, which is sufficient. They do not need high performance after boot. Misconfiguration: If they use io1 with 1000 IOPS, they would pay more for unnecessary performance. Also, if they accidentally use st1 (HDD), boot times would be extremely slow due to low IOPS. Common exam trap: The question asks for a boot volume, and candidates choose st1 because it's cheaper, but boot volumes must be SSD (gp2/gp3 or io1/io2).
SAA-C03 Objective Codes
This topic directly aligns with objective 3.1: 'High Performance' under Domain 3: 'Design High-Performing Architectures'. Specific sub-objectives include:
Selecting appropriate EBS volume types based on performance requirements.
Understanding IOPS and throughput differences.
Configuring EBS-optimized instances.
Using io2 Block Express for extreme performance.
Common Wrong Answers and Why
Choosing gp2 over gp3 for a new workload: Many candidates pick gp2 because they remember it's the older standard, but gp3 is generally better (lower cost, independent scaling). The exam tests that gp3 is the recommended general-purpose SSD.
Assuming all instance types support the same EBS bandwidth: Candidates often forget to check instance limits. For example, a t2.micro cannot achieve high IOPS even with a large io1 volume.
Thinking that io2 Block Express works with any instance: It requires specific Nitro instances that support Block Express (e.g., R5b, M5dn). Using an unsupported instance will limit performance to standard io2.
Confusing burst bucket with provisioned IOPS: Candidates think gp2 can sustain 3000 IOPS indefinitely, but it only bursts for a limited time. The exam may present a scenario where a gp2 volume runs out of burst credits and performance drops.
Specific Numbers and Terms to Memorize
gp2: 3 IOPS/GiB baseline, 3000 IOPS burst for volumes ≤1 TiB, 5.4 million I/O credits.
gp3: 3000 IOPS baseline, 125 MiB/s baseline, max 16000 IOPS and 1000 MiB/s.
io1: max 50 IOPS/GiB, up to 64000 IOPS.
io2: max 500 IOPS/GiB, up to 64000 IOPS.
io2 Block Express: max 1000 IOPS/GiB, up to 256000 IOPS, 4000 MiB/s, 64 TiB.
st1: 40 MiB/s per TB baseline, burst up to 250 MiB/s per TB, max 500 MiB/s.
sc1: 12 MiB/s per TB baseline, burst up to 80 MiB/s per TB, max 250 MiB/s.
Minimum volume sizes: 1 GiB for SSD, 125 GiB for HDD.
Edge Cases and Exceptions
gp2 volumes >1 TiB: No burst bucket; they have baseline IOPS = 3 * size (GiB) up to 16000 IOPS.
io1/io2 minimum IOPS: 100 IOPS for volumes ≤10 GiB, 1 IOPS per GiB for larger (io1) or 0.5 IOPS per GiB (io2).
Throughput limits on io1/io2: Max throughput is 1000 MiB/s, but you need enough provisioned IOPS to achieve it (e.g., for 1000 MiB/s with 16 KiB block, you need 64000 IOPS).
EBS bandwidth on instances: Some instances have higher EBS bandwidth than others; check documentation.
How to Eliminate Wrong Answers
If the question mentions 'consistent low latency' and 'high IOPS', eliminate HDD types (st1, sc1).
If cost is a concern and performance is moderate, choose gp3 over io1.
If the workload is throughput-intensive with large sequential I/O, choose st1.
If the volume is a boot volume, it must be SSD (gp2/gp3/io1/io2).
If the instance is not EBS-optimized, performance will be limited regardless of volume type.
IOPS measures operations per second; throughput measures data per second (Throughput = IOPS × I/O size).
gp3 is the recommended general-purpose SSD; gp2 uses a burst bucket that can exhaust.
io2 Block Express provides up to 256,000 IOPS and 4,000 MiB/s per volume.
EBS-optimized instances provide dedicated EBS bandwidth; required for high performance.
Instance type limits EBS bandwidth and IOPS; check documentation.
Boot volumes must be SSD (not HDD).
RAID 0 can increase IOPS and throughput but increases risk.
CloudWatch metrics (VolumeQueueLength, VolumeReadOps) help diagnose performance issues.
io1/io2 have minimum IOPS per GiB ratios.
st1/sc1 are HDD and not suitable for random I/O or boot volumes.
These come up on the exam all the time. Here's how to tell them apart.
gp3
Baseline 3000 IOPS and 125 MiB/s independent of size.
Max 16000 IOPS and 1000 MiB/s.
Cost-effective for general-purpose workloads.
No burst bucket; consistent performance.
99.8% - 99.9% durability.
io2
Provisioned IOPS up to 64000 (or 256000 for Block Express).
Higher IOPS per GiB (500 IOPS/GiB for io2).
99.999% durability (five nines).
Sub-millisecond latency for io2 Block Express.
More expensive than gp3.
Mistake
gp3 volumes have a burst bucket like gp2.
Correct
gp3 does not use a burst bucket. It provides consistent baseline performance (3000 IOPS and 125 MiB/s) and you can provision additional IOPS or throughput independently. There is no burst mechanism; performance is always at the provisioned level.
Mistake
io2 Block Express can be attached to any EC2 instance.
Correct
io2 Block Express requires a Nitro-based instance that supports Block Express, such as R5b, M5dn, C5n, etc. Attaching to an unsupported instance will cause the volume to operate as standard io2 with lower performance limits.
Mistake
Throughput is always more important than IOPS.
Correct
It depends on the workload. For transactional databases, IOPS is critical because they use small random I/O. For streaming or backup, throughput matters. The exam tests that you choose based on I/O size and pattern.
Mistake
EBS-optimized instances are optional for high performance.
Correct
EBS-optimized instances provide dedicated bandwidth to EBS. Without it, EBS traffic shares the network interface with other traffic, leading to contention and reduced performance. For any serious workload, you must use an EBS-optimized instance.
Mistake
st1 volumes are suitable for boot volumes.
Correct
st1 volumes are HDD and have low IOPS, making them unsuitable for boot volumes which require many small random reads. Boot volumes must be SSD (gp2, gp3, io1, io2).
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
IOPS (Input/Output Operations Per Second) measures the number of read/write operations per second, while throughput measures the amount of data transferred per second (e.g., MiB/s). They are related by the I/O size: Throughput = IOPS × I/O size. For small random I/O, IOPS is the key metric; for large sequential I/O, throughput is more important.
Use io2 Block Express when you need extremely high IOPS (up to 256,000) and throughput (up to 4,000 MiB/s) with sub-millisecond latency, such as for large SAP HANA or Oracle databases. Standard io2 is suitable for workloads requiring up to 64,000 IOPS and 1,000 MiB/s. io2 Block Express also requires a compatible Nitro instance.
Yes, gp3 allows you to independently provision additional IOPS up to 16,000 and throughput up to 1,000 MiB/s regardless of volume size. You pay only for the provisioned IOPS and throughput above the baseline (3,000 IOPS and 125 MiB/s).
When a gp2 volume exhausts its burst credits (stored in a 5.4 million I/O credit bucket), its IOPS drops to the baseline rate of 3 IOPS/GiB. For example, a 100 GiB volume would drop to 300 IOPS. This can cause severe performance degradation until credits accumulate again.
You can either use io2 Block Express (up to 256,000 IOPS per volume) or stripe multiple io1/io2 volumes in a RAID 0 configuration. For example, four io1 volumes at 16,000 IOPS each can provide 64,000 IOPS in RAID 0. However, RAID 0 increases the risk of data loss.
For io2 Block Express, the maximum throughput is 4,000 MiB/s. For other SSD volumes (gp3, io1, io2), the maximum is 1,000 MiB/s. For HDD volumes (st1), the maximum is 500 MiB/s per volume.
EBS encryption uses AES-256 hardware acceleration on Nitro instances, so the performance impact is minimal (usually less than 5%). For very high IOPS workloads, there may be a slight increase in latency, but it is generally negligible.
You've just covered EBS Performance: IOPS, Throughput, io2 Block Express — now see how well it sticks with free SAA-C03 practice questions. Full explanations included, no account needed.
Done with this chapter?