Considerations and limitations for blue/green deployments - Amazon Aurora
Limitations
Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China (PDF).

Considerations and limitations for blue/green deployments

Amazon RDS tracks resources in blue/green deployments with the DbiResourceId and DbClusterResourceId of each resource. This resource ID is an Amazon Web Services Region-unique, immutable identifier for the resource.

The resource ID is separate from the DB cluster ID:

Create blue/green deployment

The name (cluster ID) of a resource changes when you switch over a blue/green deployment, but each resource keeps the same resource ID. For example, a DB cluster identifier might have been mycluster in the blue environment. After switchover, the same DB cluster might be renamed to mycluster-old1. However, the resource ID of the DB cluster doesn't change during switchover. So, when the green resources are promoted to be the new production resources, their resource IDs don't match the blue resource IDs that were previously in production.

After switching over a blue/green deployment, consider updating the resource IDs to those of the newly promoted production resources for integrated features and services that you used with the production resources. Specifically, consider the following updates:

  • If you perform filtering using the RDS API and resource IDs, adjust the resource IDs used in filtering after switchover.

  • If you use CloudTrail for auditing resources, adjust the consumers of the CloudTrail to track the new resource IDs after switchover. For more information, see Monitoring Amazon Aurora API calls in Amazon CloudTrail.

  • If you use Database Activity Streams for resources in the blue environment, adjust your application to monitor database events for the new stream after switchover. For more information, see Supported Regions and Aurora DB engines for database activity streams.

  • If you use the Performance Insights API, adjust the resource IDs in calls to the API after switchover. For more information, see Monitoring DB load with Performance Insights on Amazon Aurora.

    You can monitor a database with the same name after switchover, but it doesn't contain the data from before the switchover.

  • If you use resource IDs in IAM policies, make sure you add the resource IDs of the newly promoted resources when necessary. For more information, see Identity and access management for Amazon Aurora.

  • If you have IAM roles associated with your DB cluster, make sure to reassociate them after switchover. Attached roles aren't automatically copied to the green environment.

  • If you authenticate to your DB cluster using IAM database authentication, make sure that the IAM policy used for database access has both the blue and the green databases listed under the Resource element of the policy. This is required in order to connect to the green database after switchover. For more information, see Creating and using an IAM policy for IAM database access.

  • If you want to restore a manual DB cluster snapshot for a DB cluster that was part of a blue/green deployment, make sure you restore the correct DB cluster snapshot by examining the time when the snapshot was taken. For more information, see Restoring from a DB cluster snapshot.

  • Amazon Aurora creates the green environment by cloning the underlying Aurora storage volume in the blue environment. The green cluster volume only stores incremental changes made to the green environment. If you delete the DB cluster in the blue environment, the size of the underlying Aurora storage volume in the green environment grows to the full size. For more information, see Cloning a volume for an Amazon Aurora DB cluster.

  • When you add a DB instance to the DB cluster in the green environment of a blue/green deployment, the new DB instance won't replace a DB instance in the blue environment when you switch over. However, the new DB instance is retained in the DB cluster and becomes a DB instance in the new production environment.

  • When you delete a DB instance in the DB cluster in the green environment of a blue/green deployment, you can't create a new DB instance to replace it in the blue/green deployment.

    If you create a new DB instance with the same name and ARN as the deleted DB instance, it has a different DbiResourceId, so it isn't part of the green environment.

    The following behavior results if you delete a DB instance in the DB cluster in the green environment:

    • If the DB instance in the blue environment with the same name exists, it won't be switched over to the DB instance in the green environment. This DB instance won't be renamed by appending -oldn to the DB instance name.

    • Any application that points to the DB instance in the blue environment continues to use the same DB instance after switchover.

Limitations for blue/green deployments

The following limitations apply to blue/green deployments.

General limitations for blue/green deployments

The following general limitations apply to blue/green deployments:

  • You can't stop and start a cluster that is part of a blue/green deployment.

  • Blue/green deployments don't support managing master user passwords with Amazon Secrets Manager.

  • If you attempt to force a backtrack on the blue DB cluster, the blue/green deployment breaks and switchover is blocked.

  • During switchover, the blue and green environments can't have zero-ETL integrations with Amazon Redshift. You must delete the integration first and switch over, then recreate the integration.

  • The Event Scheduler (event_scheduler parameter) must be disabled on the green environment when you create a blue/green deployment. This prevents events from being generated in the green environment and causing inconsistencies.

  • Any Aurora Auto Scaling policies that are defined on the blue DB cluster aren't copied to the green environment.

  • You can't change an unencrypted DB cluster into an encrypted DB cluster. In addition, you can't change an encrypted DB cluster into an unencrypted DB cluster.

  • You can't change a blue DB cluster to a higher engine version than its corresponding green DB cluster.

  • The resources in the blue environment and green environment must be in the same Amazon Web Services account.

  • Blue/green deployments aren't supported for the following features:

    • Amazon RDS Proxy

    • Cross-Region read replicas

    • Aurora Serverless v1 DB clusters

    • DB clusters that are part of an Aurora global database

    • Amazon CloudFormation

Aurora MySQL limitations for blue/green deployments

The following limitations apply to MySQL blue/green deployments:

  • Aurora MySQL versions 2.08 and 2.09 aren't supported as upgrade source or target versions.

  • The source DB cluster can't contain any databases named tmp. Databases with this name will not be copied to the green environment.

  • The blue DB cluster can't be an external binlog replica.

  • If the source DB cluster that has backtrack enabled, the green DB cluster is created without backtracking support. This is because backtracking doesn't work with binary log (binlog) replication, which is required for blue/green deployments. For more information, see Backtracking an Aurora DB cluster.

  • Blue/green deployments don't support the Amazon JDBC Driver for MySQL. For more information, see Known Limitations on GitHub.

Aurora PostgreSQL limitations for blue/green deployments

The following limitations apply to PostgreSQL blue/green deployments:

  • The following versions of Aurora PostgreSQL are supported as upgrade source and target versions: 11.21 and higher, 12.16 and higher, 13.12 and higher, 14.9 and higher, and 15.4 and higher. For lower versions, you can perform a minor version upgrade to a supported version.

  • Unlogged tables aren't replicated to the green environment unless the rds.logically_replicate_unlogged_tables parameter is set to 1 on the blue DB cluster. We recommend that you don't modify this parameter value after you create a blue/green deployment to avoid possible replication errors on unlogged tables.

  • The blue DB cluster can't be a self-managed logical source (publisher) or replica (subscriber).

  • If the blue DB cluster is configured as the foreign server of a foreign data wrapper (FDW) extension, you must use the cluster endpoint name instead of IP addresses. This allows the configuration to remain functional after switchover.

  • The pg_partman extension must be disabled on the blue environment when you create a blue/green deployment. The extension performs DDL operations such as CREATE TABLE, which break logical replication from the blue environment to the green environment.

  • The pg_cron extension must remain disabled on all green databases after the blue/green deployment is created. The extension has background workers that run as superuser and bypass the read-only setting of the green environment, which might cause replication conflicts.

  • The apg_plan_mgmt extension must have the apg_plan_mgmt.capture_plan_baselines parameter set to off on all green databases to avoid primary key conflicts if an identical plan is captured in the blue environment. For more information, see Overview of Aurora PostgreSQL query plan management.

    If you want to capture execution plans in Aurora Replicas, you must provide the blue DB cluster endpoint when calling the apg_plan_mgmt.create_replica_plan_capture function. This ensures that plan captures continue to work after switchover. For more information, see Capturing Aurora PostgreSQL execution plans in Replicas.

  • The pglogical and pgactive extensions must be disabled on the blue environment when you create a blue/green deployment. After you promote the green environment to be the new production environment, you can enable the extensions again. In addition, the blue database can’t be a logical subscriber of an external instance.

  • If you're using the pgAudit extension, it must remain in the shared libraries (shared_preload_libraries) on the custom DB parameter groups for both the blue and the green DB instances. For more information, see Setting up the pgAudit extension.

PostgreSQL logical replication limitations for blue/green deployments

Blue/green deployments use logical replication to keep the staging environment in sync with the production environment. PostgreSQL has certain restrictions related to logical replication, which translate to limitations when creating blue/green deployments for Aurora PostgreSQL DB clusters.

The following table describes logical replication limitations that apply to blue/green deployments for Aurora PostgreSQL.

Limitation Explanation
Data definition language (DDL) statements, such as CREATE TABLE and CREATE SCHEMA, aren't replicated from the blue environment to the green environment.

If Aurora detects a DDL change in the blue environment, your green databases enter a state of Replication degraded.

You receive an event notifying you that DDL changes in the blue environment can't be replicated to the green environment. You must delete the blue/green deployment and all green databases, then recreate it. Otherwise, you won't be able to switch over the blue/green deployment.
NEXTVAL operations on sequence objects aren't synchronized between the blue environment and the green environment.

During switchover, Aurora increments sequence values in the green environment to match those in the blue environment. If you have thousands of sequences, this can delay switchover.
Creation or modification of large objects in the blue environment aren't replicated to the green environment.

If Aurora detects the creation or modification of large objects in the blue environment that are stored in the pg_largeobject system table, your green databases enter a state of Replication degraded.

Aurora generates an event notifying you that large object changes in the blue environment can't be replicated to the green environment. You must delete the blue/green deployment and all green databases, then recreate it. Otherwise, you won't be able to switch over the blue/green deployment.

Materialized views aren’t automatically refreshed on the green environment.

Refreshing materialized views in the blue environment doesn't refresh them in the green environment. After switchover, you can manually refresh them using the REFRESH MATERIALIZED VIEW command, or schedule a refresh.

UPDATE and DELETE operations aren't permitted on tables that don't have a primary key.

Before you create a blue/green deployment, make sure that all tables in the DB cluster have a primary key.

For more information, see Restrictions in the PostgreSQL logical replication documentation.