[Enhancement]: Support for performing switchover for RDS blue green deployment

[sp055201]

Description

Currently, Terraform does not natively support performing a switchover for RDS Blue/Green deployments via a direct Terraform resource or argument. The Terraform configuration allows you to create and manage the Blue/Green environments, but the switchover action itself (switching from the Blue to the Green environment) is an operational action that typically needs to be done via the AWS Management Console, AWS CLI, or an API call.

If you perform the switchover manually outside of Terraform (e.g., using the AWS Console, CLI, or SDK), it will not automatically update Terraform’s state, leading to drift. This means Terraform will not be aware of the switchover action, and any subsequent Terraform actions might conflict or behave unexpectedly.

Affected Resource(s) and/or Data Source(s)

aws_db_instance

Potential Terraform Configuration

Terraform configuration to trigger the switchover on the aws_db_instance resource controlled by a parameter switch_over = true

References

https://github.com/hashicorp/terraform-provider-aws/blob/main/docs/design-decisions/rds-bluegreen-deployments.md

Would you like to implement a fix?

No

[github-actions]

Community Note

Voting for Prioritization

• Please vote on this issue by adding a 👍 reaction to the original post to help the community and maintainers prioritize this request.
• Please see our prioritization guide for information on how we prioritize.
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.

Volunteering to Work on This Issue

• If you are interested in working on this issue, please leave a comment.
• If this would be your first contribution, please review the contribution guide.

[lfroment0]

Hey @sp055201,
Are you sure that the switchover is not done automatically once the green db is ready for it ?
From what I see here it should be working.

As far as I could, the issue seems mostly to be that the green instance can take a long time to be ready for switchover which makes terraform hang for a while, eventually long enough for terraform to time out.

[justinretzolk]

Hey @sp055201 👋 Thank you for taking the time to raise this! As mentioned above, the switchover should be handled automatically by the provider (we wrote about this in our design decision log). Are you seeing behavior that falls outside of that?

[sp055201]

@justinretzolk, as I mentioned in the other issue,by enabling blue green deployment using below

blue_green_update {
enabled = true
}
apply_immediately=true

AWS Terraform provider is automatically performing below steps without any further input from the user.

1.provisioning the green instance
2. syncing it with the blue instance
3. triggering the switchover
4. deleting the old instance

==========================
Below are the problem statements:

1. There is no way user can control the switchover and deletion of the old instance(blue) which is totally an unexpected behaviour.

One of the purpose of creating blue green deployment is to perform maintenance tasks and schema modifications with minimal downtime[1] along with major version upgrades( using native logical replication) . So User must be able to perform schema changes/maintenance task by connecting to the green instance and user must be able to perform a switchover when READY . Right now user don't have control to do so , rather enabling blue green deployment is invoking below API calls in sequence.

CreateBlueGreenDeployment
SwitchoverBlueGreenDeployment"
DeleteDBInstance
DeleteBlueGreenDeployment

===============================
Suggestion:

Instead of controlling all of these API calls automatically while enabling blue green deployment, it should be like (how its is currently handled using AWS console or CLI:

-> blue_green_update To true -> should just CreateBlueGreenDeployment and there by a green/staging instance.

and we should have something like,

-> blue_green_switchover To true -> should invoke SwitchoverBlueGreenDeployment with means specify switchover timeout [2] ( this will allow user to connect to green instance and perform maintenance tasks and schema changes.)

-> blue_green_delete To true -> should allow user to DeleteBlueGreenDeployment with options to delete green instance or not before switchover. [3] ( Sometimes uses might wish to keep their old instance for sometime before they go ahead and delete it).

Ref:
[1]https://aws.amazon.com/blogs/database/perform-maintenance-tasks-and-schema-modifications-in-amazon-rds-for-postgresql-with-minimal-downtime/
[2]https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments-switching.html
[3]https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments-deleting.html

[justinretzolk]

Thank you for the follow up here, @sp055201. What you've described in your suggestion is what's covered in the Standalone Blue/Green Deployment Resource section of the design decision log that I mentioned in my last comment (albeit, as additional arguments rather than a separate resource). Having multiple steps like you've described, where the configuration must be edited and applied multiple times (and resource(s) imported in the midst of that), doesn't fit well with Terraform's model. While I can see what you're looking for, the AWS CLI / Console aren't really an accurate comparison to a declarative/idempotent tool like Terraform. With that in mind, the aws_db_instance resource is behaving as expected, and in a way that we're not currently interested in changing. Given that, I'm going to close this issue. If you experience any other behavior that seems unexpected, please do let us know.

[github-actions]

Warning

This issue has been closed, meaning that any additional comments are hard for our team to see. Please assume that the maintainers will not see them.

Ongoing conversations amongst community members are welcome, however, the issue will be locked after 30 days. Moving conversations to another venue, such as the AWS Provider forum, is recommended. If you have additional concerns, please open a new issue, referencing this one where needed.