A company runs a fleet of EC2 instances each attached to a 1 TiB General Purpose gp2 EBS volume. CloudWatch shows the volumes consistently use under 200 GiB of capacity and never exceed 1,000 IOPS, yet the monthly EBS bill is high because gp2 performance scales with provisioned size. A solutions architect must reduce storage cost while preserving the same usable data and current performance. Which change should the architect make?
- AMigrate each volume to Provisioned IOPS io2 at the same 1 TiB size and provision 1,000 IOPS, keeping the headroom available for occasional spikes in instance request volume.
- BTake a snapshot of each volume and restore it to a larger 2 TiB gp2 volume so the higher provisioned size delivers more baseline IOPS for the same workload at no extra charge.
- CMove the volume data to a Throughput Optimized st1 volume of 256 GiB, because st1 is the cheapest EBS type per GiB and easily covers the modest IOPS the workload currently records each month.
- DMigrate the volumes to gp3 and right-size them to 256 GiB, since gp3 includes a 3,000 IOPS baseline independent of size and bills capacity separately from performance. Correct
Why A is wrong: Tempting because io2 lets you set IOPS directly, but keeping the 1 TiB size and adding provisioned IOPS pricing raises cost rather than reducing it, so the optimisation goal is not met.
Why B is wrong: Tempting because larger gp2 raises baseline IOPS, but doubling the size doubles the storage charge and the workload does not need more IOPS, so this increases cost instead of cutting it.
Why C is wrong: Tempting because st1 has a low per-GiB price, but st1 is an HDD type built for large sequential throughput and performs poorly on the small random IO this workload runs, so it is the wrong fit.
Why D is correct: gp3 decouples IOPS from size with a free 3,000 IOPS baseline, so right-sizing to 256 GiB keeps the data and performance while sharply cutting the per-GiB storage charge.