From the RDS Console select the Aurora cluster, choose Actions → Create Blue/Green deployment; Aurora provisions a green cluster and sets up logical replication from blue to green
Apply schema changes, engine version upgrades, or parameter group changes on the green cluster while the blue cluster continues serving traffic
Monitor replication lag between blue and green in the console or via CloudWatch; wait for lag to near zero before switching
Initiate switchover: Actions → Switch over; Aurora validates health checks, waits for replication to catch up, then atomically renames blue and green endpoints (the switch typically completes in under a minute)
Validate the application against the new primary (formerly green); if issues are found, the old blue cluster is still available until you explicitly delete it
Delete the blue cluster once validated to avoid incurring double storage and instance costs
Known gotchas
For Aurora PostgreSQL, unlogged tables are not replicated to the green environment unless the rds.logically_replicate_unlogged_tables parameter is set to 1 on the blue cluster before creating the deployment
The blue cluster cannot be a logical replication publisher or subscriber at the time the blue/green deployment is created; remove any existing logical replication configurations first
Creating new partitions on partitioned tables during an active blue/green deployment is not supported for Aurora PostgreSQL — CREATE TABLE operations are not replicated to the green environment
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp