RDS io1 vs gp3 Storage: Choose the Right Volume Type
The most surprising thing about choosing between RDS io1 and gp3 storage is that gp3 can often outperform io1 for a lower cost, even for demanding workloads.
Let’s see gp3 in action. Imagine you have a busy PostgreSQL database. You’re currently on io1 and seeing high latency. You decide to provision a gp3 volume for a test. Your current io1 volume is 1TB, provisioned at 10,000 IOPS and 500 MB/s. This costs you $0.125/GB for storage + $0.065/IOPS + $0.125/MB/s, totaling roughly $125 + $650 + $125 = $900 per month.
You provision a 1TB gp3 volume. By default, gp3 gives you 3,000 IOPS and 125 MB/s throughput at $0.08/GB. So, 1TB is $80. But you need more performance. You can independently provision IOPS and throughput for gp3. You decide to match your io1 performance: 10,000 IOPS and 500 MB/s. This costs an additional $0.000015/IOPS and $0.000004/MB/s.
Total gp3 cost: $80 (storage) + (10,000 IOPS * $0.000015/IOPS) + (500 MB/s * $0.000004/MB/s) = $80 + $150 + $2 = $232 per month.
You’ve just provisioned a gp3 volume that can match your io1 performance for less than a third of the cost.
The problem gp3 solves is the rigid coupling of performance and storage in older EBS volume types like io1 and gp2. With io1, you pay for IOPS and throughput in addition to storage, and these are provisioned together. If you need more IOPS, you often have to provision more storage than you actually need, driving up costs. gp2 was better, automatically scaling IOPS with storage size, but throughput was still tied. gp3 decouples these entirely.
Internally, gp3 volumes are designed to provide a baseline performance that is not tied to storage size. You get a guaranteed 3,000 IOPS and 125 MB/s of throughput for free. Beyond that, you can scale IOPS up to 16,000 and throughput up to 1,000 MB/s independently. This allows you to tune your storage performance precisely to your application’s needs without over-provisioning storage.
The key levers you control are:
- Storage Size (GiB): The base cost of the volume.
- Provisioned IOPS: The number of input/output operations per second your volume can handle. This is crucial for transactional workloads, database operations, and any application that performs many small reads/writes.
- Provisioned Throughput (MiB/s): The maximum data transfer rate your volume can sustain. This is important for large sequential reads/writes, data warehousing, ETL jobs, and streaming applications.
The real game-changer for gp3 is its ability to scale throughput independently. While io1 offers high IOPS, its throughput is capped relative to its IOPS provisioned (1/2 IOPS in MB/s, so 10,000 IOPS maxed out at 500 MB/s). gp3 allows you to provision up to 1,000 MB/s, which is double the maximum of io1, regardless of your IOPS provision. This means you can have a volume with 10,000 IOPS and 1,000 MB/s throughput on gp3, a configuration impossible with io1 and significantly cheaper.
When you provision gp3 volumes, the cost structure is designed to be additive. You pay a base rate for storage, and then you pay a small incremental cost per IOPS and per MB/s you add beyond the baseline. This granular control means you’re only paying for the performance you actually need, making it incredibly cost-effective for a wide range of workloads, from general-purpose applications to demanding databases.
One aspect often overlooked is how gp3 handles burst performance. Unlike gp2 which had a burst capability, gp3 provides consistent baseline performance that you can then scale up. You don’t have to worry about "running out" of burst credits; if you provision 3,000 IOPS and 125 MB/s, that’s what you get, consistently. You can then choose to pay for more performance if your workload demands it, but the base is always there.
The next step after optimizing your storage type is understanding how to monitor and tune your database’s actual I/O patterns to match your provisioned performance.