Introducing fully managed Blue/Green deployments for Amazon Aurora Global Database

Amazon Aurora Global Database is designed for globally distributed applications, allowing a single Aurora database to span up to ten additional AWS Regions. It replicates your data without impacting database performance, enables fast local reads with low latency in each Region, and provides disaster recovery for your applications in case of a single Region impairment.

Organizations regularly need to perform critical database operations like version upgrades, capacity scaling, and configuration changes, but executing these updates with minimal downtime and business impact remains a challenge. Some organizations attempt these updates through self-managed blue/green deployments, where organizations set up a replica cluster to perform evaluations while keeping original production environment unchanged. Logical replication is set up to ensure data consistency, and once the new environment is validated and ready, the transition requires coordinated endpoint updates across application layers, load balancers, DNS records, monitoring tools, and downstream service dependencies. Self-managed multi-Region blue/green deployments require complex cross-Region orchestration that introduces substantial operational overhead and demands robust cross-Region failure handling mechanisms. Although these database maintenance activities are essential for improving performance and security, the traditional approaches are inadequate for mission-critical global applications.

Today, we’re introducing Amazon RDS Blue/Green support for Aurora Global Database, enabling database upgrades and modifications with minimal downtime. With just a few steps, you can create a blue/green deployment that establishes a fully managed staging (green) environment mirroring the existing production (blue) environment, including the primary and its associated secondary regions of the Global Database. The green environment stays in sync with the blue environment. Once validated, you can perform a RDS blue/green switchover, where your primary and all the secondary regions switch over to the green cluster, and your application can start accessing the new production environment without any application changes, minimizing the operational overhead.

You can use this capability for your Aurora Global Database to:

• Perform upgrades including major version upgrades (MVU), minor version upgrades (mVU), and OS upgrades
• Modify parameters, and validate new instance types and features to improve database performance
• Make schema modifications and/or rebuild indexes to support evolving application needs

The following diagram illustrates how RDS blue/green deployment is set up for Aurora Global Database across two regions.

Before RDS Blue/Green switchover, you have two clusters:

• Blue cluster – The existing production database cluster
• Green cluster – The mirrored and synchronized staging environment of the blue cluster

After RDS Blue/Green switchover, you have two clusters:

• Old blue cluster – Your original production cluster (former blue)
• (New) Blue cluster – The new version of your production cluster, where your workload will run (former green)

Getting Started

The following sections demonstrate how to use RDS Blue/Green deployments to perform a major version upgrade on an Aurora Global Database. Prior to getting started, to prepare for a blue/green deployment follow the instructions listed in Preparing for a blue/green deployment, Authorizing access to Amazon Aurora blue/green deployment operations. Note that the existing Limitations and considerations for Amazon Aurora blue/green deployments do apply for Aurora Global Databases as well.

Create a blue/green deployment

You can create a blue/green deployment using the Amazon RDS console or AWS Command Line Interface (AWS CLI). All operations must be initiated from the same Region as the writer cluster of your Aurora Global Database. In this example we show a major version upgrade from Aurora PostgreSQL 12.22 to 17.5 using the console. You can apply the same process for other types of changes mentioned before.

On the RDS console, select the Global cluster that needs to be updated and on the Actions dropdown menu, choose Create blue/green deployment, as shown in the following screenshot.

Enter the engine configurations for the green environment such as higher Engine version, DB Parameter group and DB cluster Parameter group, as shown in the following screenshots.

The green environment will use either a new DB cluster parameter group that you specify or the same parameter group as the production (blue) DB cluster or the default parameter group if the chosen parameter group is not available in the secondary Regions. Review the configuration changes on the Review and confirm step. You can also verify the estimated monthly costs for green environment as shown in the following screenshot.

You can monitor the status of blue/green deployment under the Status tab, as shown in the following screenshot.

You can also do the same procedure using the AWS CLI.

1. Create the blue/green deployment

   aws rds create-blue-green-deployment \
   --region <region> \
   --blue-green-deployment-name  <deployment-name> \
   --source  <global-cluster-arn> \
   [--target-engine-version <aurora-engine-version>] \
   [--target-db-cluster-parameter-group <parameter-group-name>]

   --target-engine-version is an optional parameter. You can select a higher major or minor version. If you specify a higher major version, you must also specify the --target-db-cluster-parameter-group.

2. View your blue/green deployment:

   aws rds describe-blue-green-deployments \
   --region <region> \
   [--blue-green-deployment-identifier <deployment-id>]\
   [--filters]

   If you specify the parameter --blue-green-deployment-identifier, the response only includes information about the specific blue/green deployment. You can use --filters to specify one or more blue/green deployments to describe.

Make changes and validate green environment before blue/green switchover

You can use the green environment to make various database changes. This includes adjusting DB instance classes or tuning parameters for one or more instances, implementing and validating newer database features, and performing maintenance tasks such as rebuilding or adding indexes, expanding table column sizes, and executing resource-intensive operations such as VACUUM FULL, and materialized view refreshes.

When using blue/green deployment for schema changes, make sure you make only replication-compatible modifications. Refer to Replication with Differing Table Definitions on Source and Replica in the MySQL documentation and Restrictions in the PostgreSQL logical replication documentation for additional details about replication-compatible changes. Validate your green environment for desired performance and detect potential issues early. To help prevent replication conflicts and accidental data modifications, we recommend maintaining the green environment in read-only mode throughout the testing process.

See Best practices for Amazon Aurora blue/green deployments for more details.

Perform the blue/green switchover

When ready, select Switch over from the Actions menu to promote the green environment to production, as shown in the following screenshot.

In the Switch over section, review the blue/green switchover settings before final switchover as shown in the following screenshot.

Prior to the switchover, Aurora runs basic checks to test the readiness of the blue and green environments for switchover. These include replication health, replication lag, and active writes in the green environment, and external replication, long-running active writes, long-running DDL statements, and MySQL/PostgreSQL compatibility in the blue environment. These guardrails stop switchovers when environments aren’t ready, helping to protect against data loss and unexpected downtime, while facilitating a reliable and predictable process.

After guardrail checks complete and blue/green switchover begins, Aurora temporarily drops existing connections to both environments, suspends writes, and waits for the green environment to synchronize with the blue environment. During switchover, Aurora renames the green environment’s clusters, instances, and endpoints to match the blue environment’s values, allowing your applications to continue operating without configuration changes. As a result, your production traffic now flows to the new production environment. You can monitor the status of switchover through Amazon EventBridge events.

To perform a blue/green switchover using the AWS CLI, run the following command:

aws rds switchover-blue-green-deployment \
--region <region> \
--blue-green-deployment-identifier <deployment-id> \
[--switchover-timeout <timeout-in-seconds>]

Refer to Switching a blue/green deployment in Amazon Aurora for the detailed switchover actions. Note that even during the RDS Blue/Green switchover process, you can perform a Global database failover, maintaining your disaster recovery capabilities.

After blue/green switchover, the former green environment becomes the new production (new blue) environment with full read/write capabilities, inheriting the original names and endpoints from the old production (former blue) environment. This ensures your applications continue operating without any configuration changes, and production traffic automatically flows to the new blue environment. The old blue environment is preserved with identifiers now carrying an “-oldn ” suffix (where n is a number), as shown in the screenshot below. This includes the global database identifier, cluster identifier, and instance identifiers.

Post-switchover tasks

Verify that your application uses the correct endpoints. If your application was connecting to the staging (green) environment for cache prewarming, update it to use the new production endpoint. While the green environment inherits your backup configurations, existing backups remain with the old blue cluster. The new production (former green) environment will begin generating its own backups immediately after switchover. To optimize costs, you can stop the old blue cluster while retaining its automated backups to meet retention requirements.

Cleanup

If you no longer need a blue/green deployment, prior to the switchover, you can delete it from the primary Region of your global database using the RDS console or by running the following AWS CLI command:

aws rds --region <region> delete-blue-green-deployment \
    --blue-green-deployment-identifier <blue green deployment identifier> \
    [--delete-target]

After a blue/green switchover is completed, the --delete-target option will not work. You’ll need to manually delete the old blue cluster, as this cleanup is not handled automatically by the above command.

Additional things to know

A couple of things to note:

• Pricing – You pay only for the resources you provision during the deployment process.
• Availability – This capability is available in all commercial AWS Regions and AWS GovCloud (US) Regions.

Conclusion

Start planning your next Aurora Global Database upgrade using RDS Blue/Green deployments. For detailed implementation guidance, refer to the documentation.

Let us know your feedback in the comments section.

About the authors