Aurora blue/green deployments
A blue/green deployment runs a full copy of a production database alongside it, keeps the copy in sync, and then swaps the two. It is the mechanism AWS provides for engine upgrades and schema changes that would otherwise require a maintenance window, and it is available for Amazon Aurora and for RDS for MySQL, MariaDB and PostgreSQL.
The alternative techniques — promoting a read replica, or queuing writes while the database is upgraded in place — both trade either downtime or complexity for the same outcome. Blue/green removes most of both, at the cost of running two environments for the duration.
How it works
Section titled “How it works”- RDS creates a green environment: a copy of the production blue cluster, including its instances and configuration.
- Replication runs continuously from blue to green, so green stays current while you work on it.
- You make the intended change in green — a major version upgrade, a parameter group change, a schema migration.
- You test against green using its own endpoints, with real production data, while blue continues to serve traffic.
- When you switch over, RDS renames the endpoints so that the green environment takes the names the application is already connecting to. No application configuration changes.
- Blue is retained afterwards and can be deleted once the change is known good.
Safety properties
Section titled “Safety properties”Switchover is guarded rather than unconditional. RDS blocks writes to both environments for the duration, waits for replication to drain, and refuses to proceed if replication lag is too high or long-running transactions are open. The switchover itself typically completes in seconds to about a minute.
Because blue is left intact and no longer receiving writes at the point of switchover, recovery from a bad change is a matter of switching the endpoints back rather than restoring from a backup.
Operating notes
Section titled “Operating notes”- Connect through the cluster and reader endpoints rather than instance endpoints, so the rename does what it is supposed to.
- Consider RDS Proxy in front of the cluster, which absorbs the reconnect for connection-pooled applications.
- Schedule the switchover deliberately; it can be timed rather than taken immediately after testing.
- Monitor both environments during the exercise, not just green.
- Delete the green environment’s predecessor once you are confident, because you are paying for both.
You pay for the green environment only while it exists, which is normally hours or days rather than continuously. That is materially cheaper than keeping a permanent standby cluster for the same purpose, and it is the reason blue/green is the default answer for a planned engine upgrade rather than a technique reserved for large ones.