gp2 to gp3 migration for Amazon RDS
In November 2022, AWS announced general availability of General Purpose SSD (gp3) storage volumes for Amazon Relational Database Service (Amazon RDS). Prior to gp3 availability customers leveraged gp2 storage volumes, and had to provision higher storage volume in order to achieve higher IOPS. With the availability of gp3, customers now have the option to provision lower storage volumes but still achieve higher IOPS and throughput. As an example customers with a requirement of 3000 IOPS but with actual database size of 100GB end up provisioning 1000 GB of gp2 volumes.
For gp3 volumes lesser than 400 GB of provisioned storage, the baseline provisioned IOPS is 3,000 and baseline throughput is 125 MiBps. Volumes greater than 400 GiB provides a baseline provisioned IOPS of 12,000 and baseline throughput of 500 MiBps. You have the option to pay for any additional IOPS or additional throughput that is above the baseline IOPS and baseline throughput. The cap is at 64000 max IOPS and 4000 MiBps max throughput per volume. Where as gp2 provides 3 IOPS per 1 GB. If you want to scale IOPS in gp2 you would have to scale the volume linearly.
While the option to leverage gp3 volumes for Amazon RDS is exciting. There might be few questions that customers might have such as:
- Is there any downtime involved while migrating the gp2 volumes to gp3?
- If there is no downtime will there be any increase in latency?
- Can we reduce the size of the volumes after migrating to gp3?
After doing multiple tests with different instance type below is my analysis:
Downtime:
There is no downtime for moving gp2 volumes to gp3. This is an in-place change.
Latency:
During the migration there shouldn’t be any noticeable increase in latency. But there might be a tail latency for a brief period.
Below are the latency numbers from my testing.
All the tests are performed using the pgbench and using the article “steps to benchmark the performance of the PostgreSQL-compatible edition” you can find the article by accessing this link .
Baseline latency while on gp2:
Command:
pgbench --host=<hostname> --username=postgres --protocol=prepared -P 60 --time=3600 --client=100 --jobs=100 postgresResults:
latency average = 289.587 msDuring storage movement to gp3
latency average = 297.652 msReducing the size of the storage volumes:
Currently when moving from gp2 to gp3. The minimum gp3 storage volume has to match the gp2 volume size. You cannot provision less that what is provisioned on gp2. That being said with a small downtime it is possible to reduce the size of the provisioned storage with a small downtime as described in this blog https://aws.amazon.com/premiumsupport/knowledge-center/rds-db-storage-size/
Cost:
While gp2 and gp3 are priced same for the storage volumes. GP3 is more cost effective in the use cases where you would need to have higher IOPS but do not want to increase the provisioned storage. If your workload requires 15,000 IOPS and has 450 GB of total data volume, With gp2 you would need to allocate 5,000 GB that would cost 5,000 GB per month x 0.23 USD * 1 instance = 1,150.00 USD (Storage Cost). With gp3 You can allocate 450 GB which would provide a baseline IOPS of 12,000 IOPS and purchase additional 3000 IOPS, That would come with a price tag of 235.0 USD (500 GB per month x 0.23 USD x 1 instances = 115.00 USD (Storage Cost), 3,000 IOPS x 0.04 USD = 120.00 USD)
The pricing I have shown above is based on the publicly available AWS pricing calculator.
Below is a snapshot of cost comparison between gp2 and gp3.
Conclusion:
The availability of gp3 for Amazon RDS will definitely add a great value to the customers and be more cost effective when trying to achieve higher IOPS but doesn’t need larger storage volumes. As I mentioned in this blog there shouldn’t be any downtime when migrating from gp2 to gp3, While based on my testing there is no noticeable increase in latency during the migration I would highly suggest on testing the change in your lower environment as would do with any other major changes.
