AWS
Microsoft Azure
Google Cloud
Key takeaways
1
The green copy starts a second cost clock, and old blue keeps charging after switchover.
2
RI coverage depends on eligible matching capacity and attributes, not DB names.
3
Storage shrink can change the economics.
3
Short test windows keep the premium controlled.
3
Rollback planning matters before switchover.
RDS Blue/Green Deployments create a synchronized staging environment so you can test database changes before switching production endpoints. While blue and green coexist, both sets of RDS resources incur charges.
For single-Region configurations, AWS says writer downtime during switchover is typically five seconds or less (AWS supported engines) . Standard RDS Blue/Green supports MySQL, MariaDB, and PostgreSQL, not Oracle or SQL Server.
The rest of this guide is built around the RDS Blue/Green Deployment cost question. Before you create a deployment, three variables decide whether the spend is worth it: how long blue and green overlap, how much of the green compute is uncovered by a Reserved Instance, and how long you keep the old-blue environment running after switchover. Everything below helps you calculate those three.
For single-Region configurations, AWS says writer downtime during switchover is typically five seconds or less (AWS supported engines) . Standard RDS Blue/Green supports MySQL, MariaDB, and PostgreSQL, not Oracle or SQL Server.
The rest of this guide is built around the RDS Blue/Green Deployment cost question. Before you create a deployment, three variables decide whether the spend is worth it: how long blue and green overlap, how much of the green compute is uncovered by a Reserved Instance, and how long you keep the old-blue environment running after switchover. Everything below helps you calculate those three.
What RDS Blue/Green actually does
AWS copies the blue production topology into a green staging environment. That can include the DB instance, Multi-AZ configuration, read replicas, storage, backups, and monitoring settings. Production changes replicate to green until switchover.
Replication varies by engine and change. For supported PostgreSQL source versions, major version upgrades use logical replication, while minor upgrades or no engine upgrade use physical replication. Physical-replication green environments are strictly read-only. MySQL and MariaDB use binary log replication.
At switchover, AWS renames endpoints so applications can keep using the production endpoint. AWS’s January 2026 update says writer downtime is typically five seconds or less for single-Region configurations. Treat that as a typical target, not a guarantee.
Major upgrades are a strong use case, especially when an older engine version is also creating RDS Extended Support costs.
Replication varies by engine and change. For supported PostgreSQL source versions, major version upgrades use logical replication, while minor upgrades or no engine upgrade use physical replication. Physical-replication green environments are strictly read-only. MySQL and MariaDB use binary log replication.
At switchover, AWS renames endpoints so applications can keep using the production endpoint. AWS’s January 2026 update says writer downtime is typically five seconds or less for single-Region configurations. Treat that as a typical target, not a guarantee.
Major upgrades are a strong use case, especially when an older engine version is also creating RDS Extended Support costs.
What the overlap really costs, by phase
There is no universal Blue/Green dollar figure because RDS pricing varies by Region, engine, instance class, deployment option, storage, I/O, and discounts. Calculate the incremental cost from your current RDS rates.
Readers budget three periods differently, so it helps to price them separately rather than lumping them into one number.
Phase 1 Pre-switchover overlap (blue and green both live):
Readers budget three periods differently, so it helps to price them separately rather than lumping them into one number.
Phase 1 Pre-switchover overlap (blue and green both live):
Overlap cost = (green compute + green storage + green I/O + green replica resources) × overlap hours
For a 72-hour test window, multiply the green hourly resources by 72. If blue has Multi-AZ or read replicas, include the corresponding green resources AWS creates.
Phase 2 Switchover day:
Phase 2 Switchover day:
Switchover cost = normal running cost for the switchover window + any brief period where both environments are billable during the cutover
Switchover itself is short, but the two environments can both be billable up to the moment the old blue is renamed and set aside.
Phase 3 Post-switchover retention (old blue kept as fallback):
Phase 3 Post-switchover retention (old blue kept as fallback):
Retention cost = old-blue compute + storage + I/O + replica resources × hours retained after switchover
AWS retains the old-blue resources after a successful switchover, and they continue to incur standard charges until you delete them.
Total temporary cost:
Total temporary cost:
Total temporary cost = Phase 1 overlap + Phase 2 switchover + Phase 3 old-blue retention
“Double cost” is a useful shorthand, but not always exact. Green may be resized or use different storage, and discounts can apply differently. For steady-state modeling after migration, use the RDS pricing calculator guide rather than a static rate.
Pre-creation cost and coverage checklist
Run this before you create billable duplicate resources:
Inventory blue topology instance class, Multi-AZ, read replicas, storage, and I/O.
Estimate green topology the resources AWS will create to mirror blue, adjusting for any resize or storage change.
Inspect unused eligible RI capacity check whether matching Reserved Instance capacity remains after blue consumes its share (see the RI section below).
Calculate uncovered compute hours the green compute hours that will bill On-Demand because no matching RI capacity covers them.
Assign a deletion owner and deadline name who deletes old blue and when, so the temporary cost stays temporary.
Should you use RDS Blue/Green?
AWS prices the resources in the green environment using normal RDS pricing for DB instances, storage, read/write I/O, backups, and other enabled features. When green closely mirrors blue, the temporary running cost can approach roughly twice the normal environment cost while both sets of resources are active. The exact increase can differ when green is resized, storage changes, or eligible discounts apply.Treat that temporary premium as one input to the decision. The real question is whether production-like testing and a controlled switchover justify the additional RDS spend for the expected overlap period.
| RDS scenario | Blue/Green cost effect | Decision guidance |
|---|---|---|
| Major or minor engine upgrade, parameter change, or supported schema change | Green runs alongside production and incurs normal RDS resource charges while you test. | Strong fit when validating the change before production and reducing switchover risk justify the temporary duplicate cost. |
| Reduce allocated storage | Green can use a smaller supported storage allocation, while the overlap still creates temporary compute and storage cost. | Compare the temporary Blue/Green premium with the ongoing storage savings after switchover. AWS requires the target allocation to remain at least 20% above current apparent storage usage. |
| Instance scaling or storage-configuration change | Green pricing reflects the target instance and storage configuration, so its cost does not have to equal blue exactly. | Use Blue/Green when validating the target configuration under production-like conditions is worth the temporary cost. |
| Small change that can safely use a normal maintenance window | Creating green introduces duplicate-resource charges that may provide limited additional value. | Compare the testing and downtime benefit with the cost of running a second RDS environment. |
| Unsupported RDS engine | A standard RDS Blue/Green deployment cannot be created for the unsupported engine. | Standard RDS Blue/Green supports MariaDB, MySQL, and PostgreSQL, not Oracle or SQL Server. |
| Keep old blue after successful switchover | Standard RDS charges continue for retained old-blue resources until they are deleted. | Set a deletion owner and deadline before switchover so fallback capacity does not become a persistent cost. |
A practical cost test is:
temporary Blue/Green premium = green resource cost during overlap + old-blue resource cost retained after switchover. Compare that premium with the operational value of testing, lower-risk cutover, and any ongoing savings created by the target configuration.
Eligibility and preflight checklist
Confirm these before committing to a deployment, because a mismatch can invalidate the plan or cause creation to fail:
Supported engine
MySQL, MariaDB, or PostgreSQL (not Oracle or SQL Server). Source and target version eligibility: confirm both versions are supported for your Region and engine.
Replication method
know whether your change uses logical or physical replication, and that physical-replication green is read-only.
Topology features
account for Multi-AZ, read replicas, encryption changes, Secrets Manager password management, external replication restrictions, and cross-Region read replicas.
Region and account scope
Blue/Green is single-Region and single-account; cross-Region or cross-account is not supported.
The reserved instance gap, correctly
An RDS Reserved DB Instance is a billing discount, not a reservation attached to a DB identifier. AWS applies the discount automatically to eligible matching usage. Eligibility depends on more than spare capacity: Region, engine, instance-family compatibility, size-flexibility (normalized-unit) rules, and deployment configuration all have to match.
Reserved Instances also discount instance usage only if they do not cover storage, backups, or I/O.
If matching RI capacity is fully consumed by blue, the new green usage can spill to On-Demand pricing. If unused matching RI capacity exists and green is eligible, it can apply to green usage. Do not assume a new green identifier automatically loses RI coverage, and do not assume spare reservation capacity exists.
Reserved Instances also discount instance usage only if they do not cover storage, backups, or I/O.
If matching RI capacity is fully consumed by blue, the new green usage can spill to On-Demand pricing. If unused matching RI capacity exists and green is eligible, it can apply to green usage. Do not assume a new green identifier automatically loses RI coverage, and do not assume spare reservation capacity exists.
How to check RI coverage before creating green
List your active RDS Reserved Instances and their attributes (Region, engine, instance class/family, size-flexibility scope, deployment option).
Compare those attributes against the green topology you plan to create.
From current billing, check how much matching RI capacity blue already consumes.
Subtract blue's consumption from the reservation's normalized capacity to see what, if anything, remains for green.
Treat any green hours beyond the remaining matching capacity as uncovered On-Demand hours.
Illustrative RI-gap formula:
Uncovered compute premium = (green On-Demand hourly rate − applicable covered hourly rate) × uncovered overlap hours
Use current billing or pricing output for both rates. For matching and normalized-unit details, see the RDS Reserved Instances guide.
Storage shrink can change the ROI
RDS normally lets you increase allocated storage but not reduce it on an existing volume. Blue/Green supports storage reduction for supported configurations, making it useful when allocated storage is much larger than current need.
AWS documents this minimum:
AWS documents this minimum:
Minimum target storage = total allocated storage × current apparent utilization × 1.2
AWS points to os.fileSys.usedPercent in Performance Insights, Database Insights, or Enhanced Monitoring for current apparent utilization (AWS: creating a blue/green deployment) .
Illustrative ROI
for a reduction from 1,000 GiB to 200 GiB:
Illustrative ROI
for a reduction from 1,000 GiB to 200 GiB:
Monthly storage savings
=
800 GiB
× current regional storage price per GiB-month
Payback months
=
temporary Blue/Green incremental cost
÷
monthly storage savings
The capacities are illustrative. Use the current AWS storage rate for your engine and Region before publishing a dollar result. See the RDS storage cost guide for the other storage components.
Warning:
Storage reduction can lengthen green-environment creation because RDS must complete storage configuration work before the environment is ready.
Engine constraints that affect testing
For PostgreSQL logical replication, complete this preflight rather than only enabling one parameter:
Use a custom parameter group and set rds.logical_replication to enabled (the default parameter group cannot be modified).
Reboot the instance after enabling logical replication so the change takes effect.
Ensure tables involved in replicated UPDATE and DELETE activity have primary keys.
Review background-worker settings (such as max worker and replication-related workers) so replication has capacity.
Monitor blue-side WAL capacity, because retained WAL can create storage pressure during the deployment.
Note external-replication restrictions and take extra care with DDL and some object-level changes.
With PostgreSQL physical replication, green is strictly read-only.
MySQL and MariaDB use binary logging. Green is read-only by default, and enabling writes can create replication conflicts, so treat green writes as an exception with a deliberate test plan.
RDS Proxy is compatible with Blue/Green for supported engines and can reduce connection disruption by detecting the topology change. It does not eliminate application retry and reconnect handling, though: existing proxy connections are dropped after green becomes the writer, and applications must re-establish them.
Test connection-pool recovery and write-error behavior during switchover. If Proxy affects your cost model, use the Switchover readiness and application recovery checklist.
A short AWS-reported downtime target does not replace operational preparation. Before you switch:
MySQL and MariaDB use binary logging. Green is read-only by default, and enabling writes can create replication conflicts, so treat green writes as an exception with a deliberate test plan.
RDS Proxy is compatible with Blue/Green for supported engines and can reduce connection disruption by detecting the topology change. It does not eliminate application retry and reconnect handling, though: existing proxy connections are dropped after green becomes the writer, and applications must re-establish them.
Test connection-pool recovery and write-error behavior during switchover. If Proxy affects your cost model, use the Switchover readiness and application recovery checklist.
A short AWS-reported downtime target does not replace operational preparation. Before you switch:
Validate replication lag is low and stable.
Schedule during low activity, avoiding long-running writes, DDL, and heavy data loading.
Test connection-pool retry and reconnect behavior, especially with RDS Proxy in the path.
Validate DNS TTL so applications pick up the endpoint change quickly.
Confirm the old-blue cleanup approval and deletion owner so retained resources do not linger.
Rollback planning
Plan rollback in three stages:
- Before switchover: Keep blue as production and delete the deployment if green fails testing.
- Failed switchover: AWS can roll back the switchover operation if it cannot complete within the configured timeout (30 to 3,600 seconds, default 300) (AWS: switching a blue/green deployment).
- After successful switchover: Old blue is retained, but AWS does not provide a one-click reverse Blue/Green switchover that reconciles new production writes. Reversal needs a recovery and data-reconciliation plan. Retained old-blue resources continue to incur charges until removed.
Implementation note (Terraform):
The HashiCorp AWS provider handles Blue/Green through the blue_green_update block on aws_db_instance, treating the deployment as an internal implementation detail rather than exposing a standalone aws_rds_blue_green_deployment resource. If you manage this as infrastructure as code, see a Terraform-specific guide for the provider details.
When Blue/Green is worth it
Use Blue/Green when a major upgrade needs production-like validation and minimal switchover downtime, when storage must be reduced, or when a critical resize should be tested before traffic moves.
Question it when a minor change can use a normal maintenance window or green may sit unused for weeks. Set an owner, target switchover date, and deletion date before creation. Those controls stop a bounded migration cost from becoming a persistent second environment.
Question it when a minor change can use a normal maintenance window or green may sit unused for weeks. Set an owner, target switchover date, and deletion date before creation. Those controls stop a bounded migration cost from becoming a persistent second environment.
How we fit after switchover
A Blue/Green change can alter the instance class or steady-state capacity you want to cover with commitments. Recalculate the stable RDS baseline after migration instead of buying more coverage because green created a temporary spike.
Our Flex Commitment program analyzes cloud usage and provides commitment recommendations. After approval, it can purchase and manage eligible commitments through cloud provider APIs.
Our documentation explains our cashback protection for eligible Flex Commitment losses, subject to applicable program terms. That means you can unlock up to 57% off On-Demand rates without owning a 1- or 3-year commitment, because we carry the commitment and refund any unused capacity as cashback or cloud credits.
Our Flex Commitment program analyzes cloud usage and provides commitment recommendations. After approval, it can purchase and manage eligible commitments through cloud provider APIs.
Our documentation explains our cashback protection for eligible Flex Commitment losses, subject to applicable program terms. That means you can unlock up to 57% off On-Demand rates without owning a 1- or 3-year commitment, because we carry the commitment and refund any unused capacity as cashback or cloud credits.
Final verdict
RDS Blue/Green is worth the temporary premium when production-like testing and a controlled switchover materially reduce migration risk.The cost depends mainly on how long green runs beside blue, whether green compute receives eligible RI coverage, and how long old blue remains after switchover.
Keep the overlap intentional, model the target RDS configuration before creation, and set a firm deletion deadline for the old environment.
If the operational benefit does not justify the temporary duplicate-resource cost, a standard maintenance path may be the better choice.
Frequently asked questions
Does RDS Blue/Green Deployment double cost?
It creates a second set of billable RDS resources, so "double cost" is useful shorthand. The exact increase depends on green configuration, storage, replicas, I/O, and eligible discounts. Charges also continue for retained old-blue resources until deletion.
Which RDS engines support Blue/Green Deployments?
Standard RDS Blue/Green supports MySQL, MariaDB, and PostgreSQL. RDS for Oracle and RDS for SQL Server are not supported. Aurora has separate Blue/Green documentation and constraints.
Can an RDS Reserved Instance cover green?
Yes, if green is eligible and matching RI capacity is available after AWS evaluates Region, engine, instance family, size-flexibility rules, and deployment configuration. The discount is not tied to the DB identifier, and it covers instance usage rather than storage, backups, or I/O. If blue already consumes matching capacity, additional green usage can be billed On-Demand.
Can Blue/Green reduce RDS storage?
Yes, for supported configurations. AWS requires the target to remain at least 20 percent above current apparent storage usage using its documented utilization calculation. Standard modification of an existing RDS volume cannot reduce allocated storage.
Can you roll back after switchover?
Do not assume a managed reverse switchover exists. AWS retains old blue after a successful switchover, but new writes occur in the new production environment. Reverting later requires a recovery plan that accounts for those writes and any schema or engine changes.
Share
Facebook
X
LinkedIn
Reddit
