Blue-green deployment is a release strategy that minimizes downtime by using two identical environments: a production environment (blue environment) for the current version and a testing environment (green environment) for the new version. The new version is first deployed and tested in the green environment. During this stage, data is kept synchronized between the blue and green environments. Once the new version is validated, traffic is switched to the green environment. By adjusting the mappings between virtual IP addresses (VIPs) and real servers (RSs), you can implement an instant switchover with an immediate rollback path without application code changes, which minimizes service downtime and risk during upgrades.
The blue-green deployment feature is available only for specific users. To use this feature submit a ticket.
Overview
What is blue-green deployment?
A blue-green deployment uses two distinct environments with identical specifications:
Blue environment: The production environment that serves live production traffic and supports both read and write operations.
Green environment: The testing environment where the new version is validated. This environment is read-only.
To ensure data consistency, a Data Transmission Service (DTS) instance is created to continuously synchronizes data between the blue environment to the green environment.
A blue-green deployment allows you to validate the functionality and performance of a new version in a real environment by redirecting traffic from the production (blue) environment to the testing (green) environment. This approach helps you quickly identify potential defects, optimize database performance, and introduce updated database features with minimal and controllable downtime.
In addition, a blue-green deployment lets you quickly roll back the original version in case of issues. This provides greater reliability and flexibility for system upgrades, significantly reducing the risks associated with database version upgrades and minimizing the impact on your business.
Scenarios
A typical scenario for blue-green deployments is upgrading the major or minor engine version of a database. The process is as follows:
Deploy the new version:
Create a green environment and select the new database version. The green environment serves as a testing environment and does not handle production traffic.
You can perform comprehensive functional and performance testing in the green environment to ensure the stability of the new version.
Switch between the blue and green environments:
After the new version is validated, switch traffic from the blue environment to the green environment.
The switch is implemented by remapping a VIP to a new RS. The instance ID and IP address of the blue environment remain unchanged during the switch, making the process simple and fast.
Monitor and roll back if required:
If a critical issue occurs after the upgrade, you can immediately roll back to the original version to restore your business.
The rollback process is fast, which significantly reduces the time required for failure recovery.
Fix issues and redeploy:
After you fix the issues in the new version, you can redeploy it to the green environment for another round of validation.
After the new version is validated, switch the traffic from the blue to the green environment again.
Benefits
Zero-downtime upgrade: Version upgrades are implemented by traffic switching. After the upgrade, the ID and IP address of the instance in the production environment remain unchanged, which ensures a persistent connection without modifying the connection settings of your application.
Rapid rollback: If an issue occurs with the new version, you can simply roll back to the original version without needing to redeploy or fix the issue.
Resource isolation: The new and original versions run in isolated environments to prevent mutual interference.
High availability: The redundant deployment ensures that sufficient resources are available to handle requests even during the traffic switch.
Prerequisites
When you create a blue-green deployment, the blue instance that serves as the production environment must meet the following requirements:
The instance runs RDS High-availability Edition and is deployed in a single zone.
The instance does not contain read-only or analytical instances.
The instance uses Premium Local SSDs, Premium ESSDs, or ESSDs.
The instance does not have the following features enabled: SSL encryption, disk encryption, column encryption, storage compression, Buffer Pool Extension, I/O performance burst, and data archiving.
Billing
Blue instance: When you create a blue-green deployment, an existing RDS instance is specified as the blue instance. This instance is billed in the same way as that before the blue-green deployment is created.
Green instance: When you create a blue-green deployment, a new green instance that serves as the testing environment is created. This instance uses the pay-as-you-go billing method. Its billing rules are the same as those for a regular pay-as-you-go RDS instance.
NoteYou can change the billing method of a green instance from pay-as-you-go to subscription. However, the 15-day free trial is available only for pay-as-you-go instances. If you convert the billing method to subscription, you will be charged based on the subscription billing rules from the moment of conversion.
Starting August 1, 2025, green instances created through blue-green deployment are free for 15 days from their creation. After 15 days, they are billed on a pay-as-you-go basis. A separate notice will be issued before the promotion ends.
Limits
After a blue-green deployment is created, the following operations and features are not supported for either the blue or green instance:
Specific configuration changes: You cannot change the instance type, storage capacity, storage type, or zone of the blue and green instances.
Data encryption features: SSL encryption, disk encryption, column encryption, and transparent data encryption (TDE).
Features of Premium ESSDs: Buffer Pool Extension (BPE), I/O performance burst, and data archiving.
The Global Active Database (GAD) feature.
Specific database operations: You cannot create and delete databases in the blue and green instances or upgrade the major engine version or update the minor engine version of the blue and green instances.
Operations on the instance public endpoint: You cannot apply for or release the public endpoint of the blue or green instances.
If the DTS instance corresponding to a blue-green deployment is deleted, you cannot switch the traffic between the blue instance to the green instance. In this case, you must first delete the blue-green deployment and then create it again.
Create a blue-green deployment
When you create a blue-green deployment, you must specify an existing RDS instance to serve as the blue instance.
Go to the RDS Instances page. In the top navigation bar, select a region. Then, click the ID of the instance that you want to use as the blue instance.
In the left-side navigation pane, choose Blue-green Deployment and then click Create Blue-green Deployment.
Select a Major Engine Version for the green instance.
Click Authorize Now and then click OK to complete the authorization of the service-linked role.
Select a Minor Engine Version for the green instance and click Create.
In the Confirm Blue-green Deployment Configurations dialog box, click OK.
Switch traffic between the blue and green instances
During the switching process, instances that use Premium Local SSDs experience one transient connection, and instances that use cloud disks experience two transient connections. We recommend that you perform this operation during off-peak hours and ensure that your application can reconnect to the instance.
Confirm the switch conditions: Before you switch the traffic, make sure the blue and green instances meet the following requirements:
The instance is in the Running state.
The instance does not contain read-only instances.
The database proxy feature is disabled for the instance.
The number and names of databases must be identical on the blue and green instances.
The number and names of database accounts must be identical on the blue and green instances.
The synchronization latency between the blue and green instances is less than 5 seconds.
Switch traffic:
Go to the RDS Instances page of the . In the top navigation bar, select the region of your blue instance. Then, click the ID of the blue instance.
In the left-side navigation pane, click Blue-green Deployment. In the Blue-green Deployment Synchronization Information section, click Switch.
Confirm the information, set the Switching Time, and then click OK. The system checks the status and configuration of the blue and green instances.
If the switch conditions are not met, resolve the issues based on the and then try again.
If the switch conditions are met, the instance status changes to Blue-green Deployment Switching. After the switch is complete, the instance status changes to Running.
Delete a blue-green deployment
You can delete a blue-green deployment in one of the following ways:
Delete only the blue-green deployment relationship:
The blue and green instances remain operational, and the limits on the instances are removed.
The green instance becomes a regular instance. It continues to use the pay-as-you-go billing method and can be converted to subscription.
Delete the blue-green deployment relationship and the green instance:
The green instance is released.
The blue instance remains operational. The limits on the blue instance are removed.
Go to the RDS Instances page. In the top navigation bar, select the region of the blue instance. Then, click the ID of the blue instance.
In the left navigation pane, click Blue-green Deployment. In the Blue-Green Deployment Synchronization Information section, click Delete.
Appendix 1: How traffic in a blue-green deployment is switched
Traffic switching from the blue environment to the green environment is a core step in a blue-green deployment. It is implemented by modifying the mappings between VIPs and RSs, as shown in the following figure
VIP: The virtual IP address used by users to access the service.
RS: The instance that provides the service.
By modifying the mappings between VIPs and RSs, you can switch traffic between the blue instance to the green instance.
Appendix 2: Pre-switch check items and error messages
Check item | Error message | Description |
Status check (Status-Check) | Current DB instance status should be active. | The database instance must be in the Running state. |
Table count (Table-Count) | The table count is different between blue and green instance. | The number of tables in the blue and green instances is different. |
DTS status (DTS-Status) | DTS status is not synchronizing. | The DTS instance is not in the Synchronizing state. |
DTS latency (DTS-Delay) | DTS delay is greater than 5 seconds. | The DTS synchronization latency is greater than 5 seconds. |
Read-only (ReadOnly) |
|
|
Database proxy (MaxScale) |
|
|
Endpoint (ConnectionString) |
|
|
Databases (databases) |
|
|
Database accounts (accounts) |
|
|