EBS performance and volume types: SOA-C03 study notes and practice questions
What to know about EBS performance and volume types for the SOA-C03 exam, from the Monitoring, Logging, Analysis, Remediation, and Performance Optimization domain (22% of the exam guide), then 1 free question to test it. Part of the SOA-C03 study guide.
EBS questions ask why a volume is slow, or which volume type to switch to.
Volume types
Type
Performance
Use
gp3
3,000 IOPS and 125 MiB/s at any size; buy more IOPS and throughput separately, up to the type’s limits
Default for most workloads
gp2
3 IOPS per GiB, bursting to 3,000 on small volumes while credits last
Older default; usually cheaper to move to gp3
io2 Block Express
Up to 256,000 IOPS, sub-millisecond latency, 99.999% durability
Critical databases
st1
Throughput-optimized HDD
Big sequential workloads, logs
sc1
Cold HDD, lowest cost
Rarely accessed sequential data
Metrics to watch
Metric
Tells you
BurstBalance (gp2, st1, sc1)
Credits left; at zero, performance drops to baseline
VolumeQueueLength
Requests waiting; a high queue means the volume can’t keep up
VolumeReadOps / VolumeWriteOps
IOPS used, to compare with what you provisioned
VolumeThroughputPercentage (io1/io2)
Share of provisioned IOPS delivered
Remember the instance’s own EBS bandwidth limit: a volume can be faster than the instance can drive. Use an EBS-optimized instance type with enough bandwidth.
Changing volumes
Elastic Volumes changes size, type, IOPS and throughput while the volume is in use. After growing a volume, extend the file system in the OS.
You must wait about 6 hours between modifications of the same volume.
Volumes restored from snapshots load data lazily from S3, so first reads are slow. Fast snapshot restore removes that delay, or pre-read the blocks.
Common traps
A gp2 volume slows down after a busy hour. BurstBalance hit zero; switch to gp3 with enough IOPS.
Making a volume bigger only for IOPS. gp3 lets you buy IOPS without storage.
Forgetting to extend the file system after resizing.
An esports league's stats database runs on a single 500 GiB gp2 EBS volume. During evening tournaments the workload needs about 4,000 IOPS for several hours.
CloudWatch shows the volume's BurstBalance metric falling to zero each evening, after which latency rises sharply.
The team wants to fix this without downtime and at the LOWEST cost.
What should a CloudOps engineer do?
Choose one answer.
AA. Use Elastic Volumes to change the volume to io2 with 4,000 provisioned IOPS while the instance keeps running.
BB. Use Elastic Volumes to grow the gp2 volume to about 1,334 GiB so that its baseline rises to 4,000 IOPS.
CC. Use Elastic Volumes to change the volume to gp3 and set 4,000 provisioned IOPS while the instance keeps running.
DD. Use Elastic Volumes to change the volume to st1, which is designed for sustained large workloads at a lower price per GiB.
C. Right: Correct. gp3 gives a 3,000 IOPS baseline at any size, with extra IOPS provisioned separately, and has no burst credits. Elastic Volumes changes the type online, so this meets the need without downtime at low cost. Learn more: General Purpose SSD volumes (opens in a new tab)
A gp2 volume earns 3 IOPS per GiB, so 500 GiB gives a 1,500 IOPS baseline and bursts above it only while credits last; a BurstBalance of zero is the sign. gp3 separates performance from size, with a 3,000 IOPS baseline and extra IOPS bought on their own, so it is usually the cheapest way to get sustained IOPS. Elastic Volumes makes the change while the volume stays in use.
Want more on EBS performance and volume types? The 5 full-length practice sets have 5 more EBS performance and volume types questions, 325 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →