This chapter covers AWS RDS Blue/Green Deployments, a feature that enables safe, simplified, and fast database updates with minimal downtime. For the SAA-C03 exam, understanding Blue/Green Deployments is critical for designing resilient architectures that require zero-downtime upgrades or changes. Approximately 5–10% of exam questions touch on database deployment strategies, and Blue/Green is a key pattern for reducing risk during modifications. By the end of this chapter, you will know exactly how Blue/Green works, when to use it, and how it differs from other update methods like in-place upgrades or read replica promotion.
Jump to a section
Imagine a Broadway play preparing for a major scene change. The director wants to switch from a worn-out set to a new, improved one without ever stopping the show. So, during the week, the crew builds an exact replica of the stage—the same dimensions, lighting rigs, and trapdoors—in a separate rehearsal hall. They install the new set there, run through the entire scene multiple times with the actors, fix any issues, and get it perfect. On opening night, when the curtain falls for intermission, the crew swiftly rolls the old set out and the new set in, using a precisely timed switch that takes only seconds. The audience never sees the change; they just enjoy the improved performance. In AWS RDS Blue/Green Deployments, the 'blue' environment is your current production database, and the 'green' environment is a cloned staging database where you apply changes (e.g., a new engine version or parameter change). The replication keeps them in sync until you're ready to 'cut over'—switching traffic from blue to green in a matter of seconds, with minimal downtime and a built-in rollback mechanism if something goes wrong.
What is RDS Blue/Green Deployments?
RDS Blue/Green Deployments is a managed feature that creates a separate, synchronized staging environment (green) for your production RDS database (blue). You can make changes to the green environment—such as upgrading the database engine version, modifying instance class, changing parameters, or altering the DB parameter group—without affecting the blue production database. Once the green environment is fully prepared and tested, you perform a switchover that promotes the green environment to become the new production database with minimal downtime (typically under one minute).
Why It Exists
Traditional database updates often require significant downtime. For example, upgrading an RDS MySQL from 5.7 to 8.0 typically involves a few minutes of downtime for the upgrade process itself, plus the risk of compatibility issues. Blue/Green Deployments reduce this downtime to a brief cutover window (usually less than 60 seconds) and provide a safe rollback path: if something goes wrong after the switchover, you can revert to the original blue environment almost instantly.
How It Works Internally
When you initiate a Blue/Green Deployment, RDS performs the following steps:
Create a read replica of the blue instance in a new DB cluster (for Aurora) or a new DB instance (for RDS). This replica is the green environment. It is created from a snapshot of the blue instance to ensure consistency.
Set up logical replication between blue and green. For RDS MySQL and MariaDB, this uses binlog replication. For PostgreSQL, it uses logical replication slots. For Aurora MySQL, it uses binlog replication; for Aurora PostgreSQL, logical replication. The green environment continuously applies changes from blue, keeping them nearly synchronized.
Apply changes to green only. You can modify the green environment—e.g., upgrade the engine version, change instance class, modify DB parameter group, or apply OS updates—without affecting blue. The replication continues during these changes, though replication may pause briefly if the green instance is restarted.
Monitor replication lag. You can view the lag in CloudWatch metrics (e.g., BlueGreenDeployment.ReplicationLag). The lag is typically sub-second when the green instance is not being modified.
Perform the switchover. When you are ready, you initiate a switchover. This does the following:
Stops write traffic to the blue instance (briefly).
Waits for replication lag to reach zero (or near zero).
Promotes the green instance to become a standalone, writable database.
Updates the DNS endpoint (the writer endpoint) to point to the green instance.
The old blue instance is retained as a standby (if you choose to keep it) or deleted.
Rollback capability. Before the switchover, you can delete the deployment at any time without affecting blue. After switchover, you can initiate a rollback to blue within a certain time window (default 30 days, configurable). This creates a new Blue/Green Deployment in reverse.
Key Components, Values, Defaults, and Timers
Switchover time: Typically under 60 seconds, but can be longer if there is a high volume of write transactions to catch up.
Replication lag: Monitored via CloudWatch metric BlueGreenDeployment.ReplicationLag (in seconds). Target lag < 1 second for smooth switchover.
Maximum retention of green environment: You can keep the green environment for up to 30 days after creation (default 30 days) before it is automatically deleted.
Rollback window: After switchover, you have a configurable period (default 30 days) to rollback to the original blue environment.
Supported engines: RDS for MySQL, MariaDB, PostgreSQL, and Aurora MySQL, Aurora PostgreSQL. Not supported for SQL Server, Oracle, or RDS for Db2.
Instance classes: Both blue and green must be the same instance class at creation, but you can modify green later.
Network: Both environments must be in the same VPC. The green environment is created in the same Availability Zone (or Multi-AZ) as blue.
Storage: The green environment uses the same storage type (e.g., gp3, io1) and size as blue initially. You can modify storage on green later.
Configuration and Verification
You can create a Blue/Green Deployment via the AWS Management Console, CLI, or API.
CLI Example:
aws rds create-blue-green-deployment \
--blue-green-deployment-name my-deployment \
--source arn:aws:rds:us-east-1:123456789012:db:my-database \
--target-engine-version 8.0.35 \
--target-db-parameter-group-name my-params \
--target-db-instance-class db.r5.largeSwitchover CLI:
aws rds switchover-blue-green-deployment \
--blue-green-deployment-identifier my-deploymentVerification:
Check status with describe-blue-green-deployments.
Monitor replication lag via CloudWatch.
After switchover, verify the new writer endpoint.
Interaction with Related Technologies
Multi-AZ: Blue/Green can be used with Multi-AZ DB instances. The green environment is also Multi-AZ if blue is.
Read replicas: If blue has read replicas, they are not automatically replicated to green. You must create new read replicas attached to green after switchover.
RDS Proxy: Blue/Green works with RDS Proxy. The proxy endpoint continues to work; during switchover, the proxy briefly disconnects connections and reconnects to the new primary.
AWS DMS: You can use DMS for more complex migration scenarios, but Blue/Green is simpler for engine upgrades within the same major version or minor version.
CloudWatch: Monitor BlueGreenDeployment.ReplicationLag and DatabaseConnections during cutover.
Limitations and Considerations
Not supported for SQL Server, Oracle, or Db2.
Cannot be used for cross-Region deployments (must be same Region).
Cannot be used for cross-account deployments.
Cannot be used for Aurora Serverless v1 (v2 supports it).
Replication lag must be minimal before switchover; high write load may cause long cutover.
Changes to the green environment may require a reboot, pausing replication briefly.
After switchover, the old blue instance is renamed (appended with -old-<timestamp>) and retained for a period (default 30 days) for rollback.
Create green environment from snapshot
RDS takes a snapshot of the blue instance and creates a new DB instance (green) from that snapshot. This ensures both environments start with identical data. The green instance is created in the same VPC, subnet group, and security groups as blue. During this step, the blue instance remains fully operational. The green instance is initially in a 'creating' state and then becomes available. Replication is not yet active; it starts after creation.
Set up logical replication
RDS configures logical replication from blue to green. For MySQL/MariaDB, this uses binary log (binlog) replication; for PostgreSQL, logical replication slots. The green instance acts as a replica that applies changes from blue in near real-time. RDS automatically manages the replication credentials and configuration. You can monitor the replication lag via CloudWatch metric `BlueGreenDeployment.ReplicationLag`. Typical lag is sub-second under normal load.
Apply changes to green environment
You can now modify the green environment—upgrade engine version, change instance class, modify parameter groups, or apply patches. These changes do not affect the blue instance. However, if the green instance requires a reboot (e.g., for engine version upgrade), replication will pause during the reboot and resume automatically. It is recommended to test the green environment thoroughly before switchover. You can also connect to the green endpoint (read-only) to verify data consistency.
Monitor and validate replication
Before initiating switchover, ensure replication lag is minimal (ideally zero). You can view the lag in CloudWatch. Also, validate that any schema changes or data modifications in blue are correctly propagated to green. If you have made changes to green (e.g., parameter changes), ensure they do not cause replication errors. RDS provides a `BlueGreenDeployment.ReplicationStatus` metric to indicate if replication is healthy.
Initiate switchover
When ready, you call the switchover action. RDS first stops write traffic to blue (briefly), waits for replication lag to reach zero, then promotes green to be the new primary. The DNS endpoints are updated to point to green. The entire process typically takes less than 60 seconds. During this time, existing connections to blue are dropped; applications should retry with the new endpoint. After switchover, the old blue instance is renamed and retained for rollback.
Enterprise Scenario 1: Major Version Upgrade for a Financial Services Database
A financial services company needed to upgrade their RDS for MySQL 5.7 database to 8.0 to meet compliance requirements. The database supported a critical trading application with strict uptime SLAs. Traditional in-place upgrades required 10–15 minutes of downtime, which was unacceptable. Using Blue/Green Deployments, they created a green environment with MySQL 8.0, ran the upgrade there, and conducted extensive testing with synthetic transactions. They monitored replication lag and ensured it stayed under 100ms. During the next maintenance window, they performed the switchover, which completed in 45 seconds. The application experienced only a brief connection interruption. Post-switchover, they kept the blue environment for 7 days as a rollback option. The key learning was to ensure all stored procedures and triggers were compatible with the new version before switchover; they found an issue with a deprecated function that was fixed in green before cutover.
Enterprise Scenario 2: Instance Class Upgrade for a High-Traffic E-Commerce Platform
An e-commerce platform running Aurora PostgreSQL needed to scale up from db.r5.large to db.r5.xlarge to handle holiday traffic. They used Blue/Green Deployments to create a green environment with the larger instance class. During the process, they also modified the DB parameter group to increase work_mem for better query performance. The replication lag was consistently below 50ms. They performed the switchover during a low-traffic period (3 AM), and the cutover took 30 seconds. The application had connection pooling via RDS Proxy, which automatically reconnected to the new primary. Post-switchover, the old blue instance was retained for 24 hours in case of issues. One common mistake in this scenario is forgetting to update read replicas; they had to create new read replicas attached to the new green instance after switchover.
Common Pitfalls
High replication lag: If the green environment is heavily modified (e.g., upgrading engine version and changing instance class simultaneously), replication may lag significantly, extending the cutover window. Always test with representative load.
Incompatible parameters: Applying parameter changes that are incompatible with the new engine version can cause replication to fail. Always validate parameter groups in a non-production environment first.
Forgetting to update application endpoints: While the DNS endpoint changes automatically, applications that cache the endpoint may still point to the old blue instance. Use RDS Proxy or a connection broker to abstract the endpoint.
Not planning for rollback: After switchover, the blue environment is retained for a limited time. Ensure you have a rollback plan and test it before the retention period expires.
What SAA-C03 Tests on RDS Blue/Green Deployments
The SAA-C03 exam tests your ability to choose the right deployment strategy for database updates with minimal downtime. Specifically, objective 2.3 (Resilient Architectures) expects you to know when to use Blue/Green Deployments versus other approaches like in-place upgrades, read replica promotion, or snapshot restore. The exam focuses on:
Use cases: Major engine version upgrades, instance class changes, parameter group modifications, and OS patching with minimal downtime.
Limitations: Not supported for SQL Server, Oracle, or Db2. Not for cross-Region or cross-account. Not for Aurora Serverless v1.
Switchover time: Typically under 1 minute.
Rollback: Possible within a configurable window (default 30 days).
Replication lag: Must be monitored; high lag can delay switchover.
Common Wrong Answers and Why Candidates Choose Them
'Use a read replica and promote it': Candidates often think promoting a read replica is sufficient. However, promoting a read replica requires manual steps, and the new instance is not automatically synchronized with the original; you lose the original as a rollback option. Blue/Green provides a managed, reversible process.
'Perform an in-place upgrade during a maintenance window': In-place upgrades cause downtime (often several minutes) and lack a rollback option. Blue/Green reduces downtime to seconds and provides rollback.
'Use AWS DMS for continuous replication and then switch': DMS is more complex and typically used for heterogeneous migrations or ongoing replication. For simple version upgrades, Blue/Green is simpler and faster.
'Blue/Green Deployments are only for Aurora': False. Blue/Green works for RDS MySQL, MariaDB, PostgreSQL, and Aurora. But not for SQL Server/Oracle.
Specific Numbers and Terms That Appear on the Exam
Switchover time: 'under 1 minute' or 'less than 60 seconds'.
Rollback window: 'up to 30 days' (default).
Replication lag metric: BlueGreenDeployment.ReplicationLag.
Supported engines: MySQL, MariaDB, PostgreSQL, Aurora MySQL, Aurora PostgreSQL.
Not supported: SQL Server, Oracle, Db2, Aurora Serverless v1.
Edge Cases and Exceptions the Exam Loves to Test
Multi-AZ: Blue/Green works with Multi-AZ; the green environment is also Multi-AZ.
Read replicas: Blue/Green does not automatically replicate read replicas. You must create new read replicas after switchover.
RDS Proxy: Works seamlessly; proxy endpoints are updated automatically.
Aurora Global Database: Blue/Green is not supported for global database clusters.
How to Eliminate Wrong Answers Using the Underlying Mechanism
If a question asks for a solution to upgrade a database with minimal downtime and rollback capability, and the options include in-place upgrade (downtime), snapshot restore (data loss), or read replica promotion (manual, no rollback), Blue/Green is the correct choice. Eliminate options that don't support the required engine or that involve cross-Region scenarios.
Blue/Green Deployments provide near-zero downtime (< 1 minute) for database updates with a managed rollback option.
Supported engines: RDS MySQL, MariaDB, PostgreSQL, and Aurora (MySQL and PostgreSQL).
Not supported for SQL Server, Oracle, Db2, or Aurora Serverless v1.
Replication lag must be minimal before switchover; monitor using CloudWatch metric BlueGreenDeployment.ReplicationLag.
After switchover, the old blue environment is retained for a configurable period (default 30 days) for rollback.
Read replicas are not automatically migrated; create new ones after switchover.
Blue/Green works with Multi-AZ and RDS Proxy.
Cannot be used for cross-Region or cross-account deployments.
Switchover is initiated via the AWS Management Console, CLI, or API.
Always test the green environment thoroughly before switchover.
These come up on the exam all the time. Here's how to tell them apart.
RDS Blue/Green Deployments
Minimal downtime (< 1 minute) during switchover.
Built-in rollback capability (retains old environment).
No risk to production during testing; changes applied only to green.
Supports engine version upgrades, instance class changes, and parameter modifications.
Requires same Region and VPC; not for all engines.
In-Place Upgrade (Maintenance Window)
Downtime typically 5–15 minutes for major upgrades.
No automatic rollback; must restore from snapshot.
Risk of incompatibility or failure during upgrade; impacts production directly.
Limited to engine version upgrades (not instance class or parameters).
Works for all RDS engines (including SQL Server/Oracle).
Mistake
Blue/Green Deployments cause zero downtime.
Correct
Switchover typically takes under 60 seconds, during which the database is briefly unavailable. It is not zero downtime, but minimal downtime (often called 'near-zero').
Mistake
You can use Blue/Green Deployments for any RDS engine.
Correct
It is only supported for MySQL, MariaDB, PostgreSQL, and Aurora (MySQL and PostgreSQL). Not for SQL Server, Oracle, or Db2.
Mistake
After switchover, the old blue environment is deleted immediately.
Correct
The old blue environment is retained for a configurable period (default 30 days) and renamed. You can use it for rollback.
Mistake
Blue/Green Deployments can be used for cross-Region migrations.
Correct
Both blue and green must be in the same Region and same VPC. For cross-Region, use read replicas or DMS.
Mistake
You can modify the blue environment during the deployment.
Correct
You should not modify the blue environment (e.g., change parameters) while a Blue/Green deployment is active, as it may cause replication issues. Changes should be made only to green.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Promoting a read replica creates a new standalone database from a replica, but the original database remains unchanged. You must manually redirect traffic, and there is no built-in rollback to the original. Blue/Green Deployments automate the entire process, including DNS endpoint updates, and provide a one-click rollback to the original environment. Blue/Green also allows you to make changes to the green environment (like engine upgrades) that are not possible on a read replica.
Yes, that is a common use case. You create a green environment with the target engine version (8.0), test it, and perform a switchover. Ensure your application is compatible with MySQL 8.0 before switchover. Also note that Blue/Green supports major version upgrades for MySQL, MariaDB, and PostgreSQL.
Typically under 60 seconds. The actual time depends on the amount of write transactions that need to be replicated during the final catch-up. If replication lag is high, the switchover may take longer. It is recommended to perform switchover during low traffic periods.
Existing connections to the blue instance are dropped. Applications should be designed to retry connections. Using RDS Proxy can help minimize disruption as it handles connection draining and reconnection transparently.
Yes, Aurora Serverless v2 supports Blue/Green Deployments. Aurora Serverless v1 does not.
Use the CloudWatch metric `BlueGreenDeployment.ReplicationLag` (unit: Seconds). You can also view the lag in the RDS console under the Blue/Green deployment details. Aim for lag under 1 second before initiating switchover.
Yes, you can modify the instance class, storage, and parameter group of the green environment after it is created. These changes do not affect the blue environment. However, modifications that require a reboot (e.g., instance class change) will temporarily pause replication.
You've just covered RDS Blue/Green Deployments — now see how well it sticks with free SAA-C03 practice questions. Full explanations included, no account needed.
Done with this chapter?