A computer-aided dispatch (CAD) database on Amazon EC2 uses Amazon EBS. Metrics show moderate IOPS needs well within gp3 capabilities, but the volume was provisioned as io2 for “future proofing.” What cost-aware storage change should the architect recommend?
Select an answer to reveal the explanation.
Short Explanation
Paying io2 prices for gp3-level IOPS is like leasing a race car to drive to the grocery store. Right-size to gp3 when metrics say you don’t need extreme provisioned IOPS. Extra idle io2 disks, Glacier for CAD queries, or blind HDD swaps miss the cost/performance match.
Full Explanation
Preferring Amazon EBS gp3 instead of io2 when CAD database metrics show moderate IOPS well within gp3 capabilities is the cost-aware right-sizing move. Io2’s provisioned high-performance model costs more; paying for unused extreme IOPS on a computer-aided dispatch database is wasteful when gp3 meets measured needs with baseline and burst/provisioned IOPS flexibility at lower price. Adding three unused io2 volumes in every Availability Zone only increases the bill without improving the measured workload. Migrating database files to Amazon S3 Glacier Flexible Retrieval cannot support sub-millisecond (or even interactive transactional) CAD queries; Glacier is archival object storage, not a database disk. Switching root and data to Magnetic HDD regardless of latency needs risks CAD responsiveness for a workload that still has latency sensitivity even if IOPS are moderate. Exam caveat: validate peak IOPS, throughput, and latency SLOs before changing volume type; gp3 can provision IOPS/throughput independently, but extreme latency-sensitive or very high IOPS cases may still justify io2. Operational check: capture CloudWatch Volume* metrics under dispatch load, pilot a gp3 volume in non-prod with identical sizing, compare latency/IOPS headroom, then plan a maintenance cutover with validated snapshots/AMIs.