A database team runs a 2-TB PostgreSQL instance needing 12,000 IOPS with bursty throughput, costs have spiked on Provisioned IOPS volumes, performance must stay consistent, and they want independent scaling of IOPS and throughput without overprovisioning. Which block storage selection controls IOPS cost while meeting performance?

The correct choice works because gp3 decouples provisioned IOPS (up to 80,000) and throughput (up to 2,000 MiBps) from volume size and charges only for provisioned performance above free baselines, so a 2-TB PostgreSQL volume can hold 12,000 consistent IOPS for random database reads and writes while scaling bursty throughput independently without paying the Provisioned IOPS premium or enlarging capacity. The gp2 overprovisioning idea fails on coupling and economy because gp2 derives baseline IOPS directly from size at three IOPS per GiB, so reaching 12,000 sustained IOPS forces roughly 4 TB of unused capacity and violates the explicit no-overprovisioning and cost-control goals despite delivering steady performance. The retained io2 idea fails on cost efficiency because while io2 easily meets consistent low-latency 12,000 IOPS and supports mission-critical durability, autoscaling capacity does not lower the high per-IOPS provisioned charge that caused the spike nor does it provide gp3-style independent throughput scaling. The striped st1 idea fails on workload profile because Throughput Optimized HDD in RAID 0 is excellent and economical for sequential, large-block bursty throughput such as logs or data lakes but cannot deliver 12,000 random IOPS with single-digit millisecond consistency required for transactional PostgreSQL. For exams, remember that burst credits and HDD throughput are not substitutes for provisioned SSD IOPS when consistency is stated, and always validate in practice with CloudWatch VolumeWriteOps, VolumeReadOps, queue length, latency, and ThroughputPercentage against instance EBS bandwidth limits before committing to IOPS and throughput values.