Migrate io1 to io2 Block Express storage for Amazon RDS workloads using blue/green deployments

Amazon Relational Database Service (Amazon RDS) provides two storage types: Provisioned IOPS SSD and General Purpose SSD. They differ in performance characteristics and price, which means that you can tailor your storage performance and cost to the needs of your database workload. In this post, we show how you can migrate from io1 to io2 Block Express Provisioned IOPS SSD storage.

io2 Block Express storage is designed for critical database workloads that require high performance and high throughput at low latency. io2 Block Express storage delivers consistent sub-millisecond latency for database workloads with enhanced durability at 99.999% (versus io1’s 99.9%), offering 20 times greater IOPS per GiB of provisioned storage—up to 1,000 IOPS per GiB compared to io1’s 50:1 ratio—all at the same price as io1.

You can upgrade from io1 storage to io2 Block Express storage without downtime, significantly improving the performance and reliability of your applications without increasing storage cost. For production workloads, we recommend performing online migration during off-peak hours or scheduled maintenance windows. While online migration is the preferred approach, some organizations may need to use a blue/green deployment strategy due to specific change management requirements such as additional control, extensive testing, validation, and quick rollback capabilities.

For this post, we focus on the blue/green deployment strategy for Amazon RDS for PostgreSQL DB engines, though similar approaches can be applied to MySQL and MariaDB engines as well. The managed blue/green deployment feature isn’t currently supported for Oracle or SQL Server engines.

Solution overview

For organizations with strict change management requirements, a blue/green deployment strategy offers a comprehensive approach for migrating from io1 to io2 Block Express storage. The blue/green deployment strategy involves running two identical production environments: the blue environment representing the current live system with io1 storage, and the green environment configured with the target io2 Block Express storage.While the approach of using a blue/green deployment ensures minimal performance disruption and meets stringent change management constraints, it does introduce temporary infrastructure costs by maintaining parallel environments. Although migrating to io2 Block Express doesn’t increase storage costs compared to io1, you should carefully factor in the additional infrastructure expenses and align the approach with your budget and operational requirements.The following diagram presents a high-level architectural overview of blue/green deployment, focusing on core components while abstracting network and security implementation details.

The flexibility offered by blue/green deployment ensures various operational constraints can be accommodated while following AWS best practices for RDS storage modifications.

Prerequisites

For this walkthrough, make sure you have the following resources:

• An AWS account
• An RDS for PostgreSQL DB instance with io1 storage and logical replication enabled (this is required for blue/green deployments)

Limitations and considerations for Amazon RDS blue/green deployments

Before proceeding ahead with blue/green deployments in Amazon RDS, carefully consider factors such as replication slots, resource management, instance sizing, and potential impacts on database performance. For limitations and considerations for Amazon blue/green deployments, refer to Amazon RDS User Guide.

Migrate storage using blue/green deployment strategy

To perform a migration using blue/green deployment, complete the following steps:

1. On the Amazon RDS console, choose Databases in the navigation pane.
2. Select the DB instance that you want to copy to a green environment, and on the Actions menu, choose Create Blue/Green Deployment.
3. For Blue/Green Deployment identifier, enter a name.
4. Choose Next.

5. Under Engine configurations, choose the engine version and the DB parameter group for the green database.

6. Leave the settings for Instance configuration as is or choose a new DB instance class for the green database.
7. Under Storage, for Green instance storage configuration, choose Provisioned IOPS SSD (io2) for Storage type.

8. Choose Next.
9. On the Review and confirm page, review the details, then choose Create to initiate the process of creating the green environment.
10. To view the details of the blue/green deployment, choose Databases in the navigation pane and choose the blue/green deployment from the database list.

11. Choose the Status tab to monitor the blue/green deployment status. You can track the deployment status using AWS Management console or describe-blue-green-deployments AWS CLI command.

12. When the green environment status changes to Completed and the switchover mapping status is Available, perform thorough testing and validation on the green environment, following the best practices outlined later in the section “Best practices for certifying and validating io2 Block Express storage for blue/green deployments“. Make sure that the green environment meets your performance, data durability, and compatibility requirements before proceeding further.
13. After the green environment is validated, choose Databases in the navigation pane and select the blue/green deployment that you want to switch over.
14. On the Actions menu, choose Switch over.
15. Review the summary page to make sure the resources in both environments match what you expect.

16. Under Timeout settings, select the time limit for switchover. You can specify a switchover timeout period between 30 seconds and 3,600 seconds (one hour). If the switchover takes longer than the specified duration, then any changes are rolled back and no changes are made to either environment. The default timeout period is 300 seconds (five minutes).
17. Choose Switch over to switch the production traffic from the blue database to the green database.

After the switchover is complete, the DB instance that was in the green environment becomes the new production DB instance (new blue). The DB instance in the previous blue environment is renamed by appending -oldn to the current name (old blue), where n is a number.

Migrate storage using in-place storage type change

If there is no specific change management requirement from your organization, Amazon RDS storage migration from io1 to io2 Block Express storage can be performed through one simple action, without incurring downtime. To perform this, complete the following steps:

1. On the Amazon RDS console, choose Databases in the navigation pane.
2. Select the DB instance with io1 storage that you want to migrate to io2 Block Express storage.
3. Choose Modify.
4. Under Storage, change Storage type from Provisioned IOPS SSD (io1) to Provisioned IOPS SSD (io2).

5. Choose Continue.
6. Choose Apply immediately.
7. Review the modification summary and choose Modify DB instance to initiate the migration.

Amazon RDS will apply these changes immediately. Storage modification doesn’t require any outage and doesn’t degrade performance of the server. This straightforward process allows you to quickly enhance your database performance and take advantage of io2 Block Express storage’s improved durability while maintaining continuous database availability at the same cost.

Best practices for certifying and validating io2 Block Express storage for blue/green deployments

To certify and validate the migration of io1 storage to io2 Block Express storage, you should consider the following factors to test, monitor, and have a rollback plan in place to achieve a successful migration:

• Performance testing: Conduct comprehensive performance testing to validate the expected performance improvements of the io2 Block Express storage. This should involve simulating production workloads, benchmarking, and comparing the results with the existing io1 storage setup. Reference the Benchmark Amazon RDS for PostgreSQL blog post for more information.
• Compatibility testing: Thoroughly test the application stack, including custom scripts, stored procedures, and database connectors, to identify and address any potential issues or conflicts before the production deployment. Validate compatibility with the underlying database engine, including any version-specific features or dependencies. Refer to the Upgrades of the RDS for PostgreSQL DB engine documentation for guidance.
• Monitoring and alerting: Establish comprehensive monitoring and alerting mechanisms to proactively detect and respond to any anomalies or performance issues during and after the migration. Configure Amazon CloudWatch metrics for RDS and alarms to monitor key performance indicators, such as IOPS, throughput, and latency. Leverage Amazon CloudWatch Database Insights for detailed database performance insights and real-time, granular metrics.
• Rollback plan: Develop a well-defined rollback plan to revert to the previous io1 storage configuration if any critical issues arise during or after the migration. The rollback plan should include steps to restore the previous database instance, migrate the data back, and redirect traffic to the old environment. Ensure that deletion protection is disabled on the database instance before initiating the rollback process.
• Operational readiness: Ensure that the team is trained and familiar with the blue/green deployment process, the monitoring tools, and the rollback procedures. Conduct dry runs and tabletop exercises to validate the end-to-end migration process and the ability to execute the rollback plan if necessary.

Clean up

To prevent unwanted charges, complete the following steps to clean up the blue/green deployment and the associated old blue database. Before deleting the database, make sure deletion protection is disabled on the DB instance.

1. On the Amazon RDS console, choose Database in the navigation pane.
2. Select the blue/green deployment that you want to delete, and on the Actions menu, choose Delete.
3. Enter delete me in the box and choose Delete to permanently delete the blue/green deployment.
4. Select the old blue database (appended with -oldn), and on the Actions menu, choose Delete.
5. Enter delete me in the box and choose Delete to permanently delete the DB instance.

Conclusion

Migrating from io1 to io2 Block Express storage represents a strategic opportunity to enhance your database performance without increasing storage costs. In this post, we demonstrated how to achieve minimum downtime and implement a risk-minimized migration using blue/green deployments, follow best practices for testing and validation, and establish proper monitoring and rollback procedures.The benefits of io2 Block Express storage are compelling—it offers sub-millisecond latency for critical workloads, enhanced durability (99.999%), up to 20 times more IOPS/GiB from provisioned storage, and the same cost structure as io1 storage.For a successful migration, remember these key takeaways:

• Always test thoroughly in a development environment first.
• Implement comprehensive monitoring before, during, and after migration.
• Maintain detailed rollback plans for risk mitigation.
• Follow the blue/green deployment strategy for workloads that requires adherence to change management requirements that don’t allow for online migration.
• Validate performance metrics against your baseline requirements.

As organizations continue to demand higher performance and reliability from their database workloads, io2 Block Express storage provides a clear path forward. By following the approach outlined in this post, you can confidently modernize your storage infrastructure while maintaining business continuity.

About the authors