hashicorp / terraform-provider-aws

The AWS Provider enables Terraform to manage AWS resources.
https://registry.terraform.io/providers/hashicorp/aws
Mozilla Public License 2.0
9.74k stars 9.1k forks source link

[Enhancement]: Change the VPC for an Amazon RDS DB instance #27459

Open DenisBY opened 1 year ago

DenisBY commented 1 year ago

Description

We need to change VPC for RDS. According to AWS documentation, it should be straightforward. However, we are getting the error:

Error: updating RDS DB Subnet Group (rds-prod-20220602121811550200000001): InvalidParameterValue: The new Subnets are not in the same Vpc as the existing subnet group status code: 400

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

Potential Terraform Configuration

No response

References

https://aws.amazon.com/premiumsupport/knowledge-center/change-vpc-rds-db-instance/

Would you like to implement a fix?

No response

github-actions[bot] commented 1 year ago

Community Note

Voting for Prioritization

Volunteering to Work on This Issue

md5 commented 1 year ago

Can you elaborate on what you're doing? It looks like you have updated the subnet_ids of an existing DB Subnet Group to be subnet IDs from a different VPC?

The docs for ModifyDBSubnetGroup don't mention throwing InvalidParameterValue, but it appears that the API doesn't support changing to subnets that are in a different VPC than the one where the DB Subnet Group was originally created. This matches the behavior of the AWS RDS web console, where you can only choose subnets from the same VPC as the existing subnets that are already in use.

I believe the way the blog post you cite expects you to handle this is to actually create a new DB Subnet Group, so I think that's what you'll want to do here as well. In order to do that, I think you'll need to create it with a different resource identifier in your Terraform config unless you want to muck around with state rm and deleting the old subnet group manually after you have switched the instance to use the new subnet group.

At some level, it would be nice if this provider could detect when you are passing a list of subnets from a new VPC and force the creation of a new DB Subnet Group in that case to replace the old one. It looks like this would be possible if the schema resource implemented CustomizeDiff for the subnet_ids attribute. However, this probably goes too far down the road of reproducing AWS business logic in the provider itself.

DenisBY commented 1 year ago

Thank you for the prompt answer. We created a new VPC and would like to move our RDS DB to this new VPC. Correct, there should be a logic for 'detect when you are passing a list of subnets from a new VPC and force the creation of a new DB Subnet Group in that case to replace the old one'. Like 'create before destroy'. And it seems it's too complicated to use for such edge case.

I did it by manually creating a new DB Subnet Group and with state rm, -refresh-only, import, etc magic.