changing identifier in RDS (aws_db_instance) will destroy/create the db

[hashibot]

This issue was originally opened by @adrianlop as hashicorp/terraform#11636. It was migrated here as part of the provider split. The original body of the issue is below.

---

Terraform Version

0.8.5

Affected Resource(s)

• aws_db_instance

Expected Behavior

Using AWS RDS UI you can change the identifier and it won't recreate the database, it will only apply it on the preferred maintenance window/apply immediately if you select it.

This change also changes the endpoint, so AWS will give you a warn as expected: Warning! Endpoint will also change.

Actual Behavior

Terraform will destroy + recreate the instance. It should only apply the change in the maintenance window or immediately if you selected apply_immediately=true, not destroy the DB.

Thanks.

[fernviridian]

This would be great if Terraform didn't try to destroy my DB instances when doing a "DB instance identifier change". Something you can do easily in the AWS console. So my current workaround is to change the db instance id via AWS console, manually change my tfstate json, and then run terraform plan and terraform apply to make sure it's all good.

[catsby]

It looks like this is supported via NewDBInstanceIdentifier in the ModifyDBInstance call. It should be straightforward to change, however we need to ensure that we update the local resources ID, as it uses DBIdentifer as it's key

[Geartrixy]

Hi,

has any progress been made here?

Thanks!

[zoi-aschmid]

Hi,
I really recommend that renaming can be possible without deletion!

Thanks!
Alex

[baptiste-mnh]

Hi,
I agree, this could be really helpful!
It's quite time consuming.

Thanks!

[yeukhon]

It looks like this is supported via NewDBInstanceIdentifier in the ModifyDBInstance call. It should be straightforward to change, however we need to ensure that we update the local resources ID, as it uses DBIdentifer as it's key

AWS does support an unique identifier:

DbiResourceId (string) --
The AWS Region-unique, immutable identifier for the DB instance. This identifier is found in AWS CloudTrail log entries whenever the AWS KMS key for the DB instance is accessed.
https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DBInstance.html

[piyat]

I ran into this one today as we wanted to change naming convention. If anyone else hits this you can work around with some state tinkering:

change instance identifier in the AWS console (fair warning, will cause instance to be unavailable while RDS endpoint will changes, for about 10 mins).
backup state: terraform state pull > backup.tfstate
find address of instance with old name: terraform state list | grep aws_db_instance (if you have more than instance in state, find the right one)
remove state for instance with old name: terraform state rm 'address'
import state for instance with new name: terraform import --var-file=<any var files> 'address' <new instance identifier>
run tf apply, should be good in most cases.. in my case, I had a bunch of resources whose names changed too, including option + parameter groups which can't be deleted without being detached from the rds instance.. I switched the instance to use default and after instance finished modifiying ran tf apply again and now everything's in sync.

This is very convoluted so keen for a fix 🙏

[azuenko]

We wait for this fix with impatience. Our restore from the backup process involves creating a duplicate DB instance, moving the data there, removing/renaming the old instance and finally renaming the new instance to match the old one, so the endpoint remains unchanged. Without this feature we're forced to use the console and direct state modification, which requires the operator to have the access AWS account through the UI and access keys. It is not desirable from security perspective, as we want Terraform Cloud to be the only way to access AWS.

[dee-kryvenko]

I think I figured out how to make it work - but it will be backward incompatible change (id will be resource_id now instead of identifier). Working on a PR #16782 - still have to update tests and docs, will try to get it done tomorrow.

[dee-kryvenko]

Alright I think I finished with tests and docs... that's crazy how long tests runs since pretty much any action agains RDS takes literally forever :(
Can somebody review #16782 please?

[dee-kryvenko]

Also looking into the code I realized that aws_rds_cluster, aws_rds_cluster_instance and aws_rds_global_cluster (and probably more?) all have the same problem and should be fixed separately. I do not have plans to fix them too at this time, at least not until my DBA team confirms they are affected by any of these too - but at least I hope the change to aws_db_instance provides some groundwork and general approach.

[vicyap]

What should happen if the identifier_prefix is updated? Should this create a new resource or update the current resource with the new value?

[dee-kryvenko]

I think the rule of thumb is - as long as the resource address in the state file stays the same, providers should put in their best effort to avoid resource re-creation. Not sure if I covered this in my PR, probably not - it's been over a year now.

[breathingdust]

Hi all 👋 Just letting you know that this is issue is featured on this quarters roadmap. If a PR exists to close the issue a maintainer will review and either make changes directly, or work with the original author to get the contribution merged. If you have written a PR to resolve the issue please ensure the "Allow edits from maintainers" box is checked. Thanks for your patience and we are looking forward to getting this merged soon!

[ewbankkit]

As this would change the resource ID it is considered a breaking change and should be implemented in a major version.

[L3tum]

We just ran into this issue ourself. An innocent naming change that would allow us to monitor the DB better just deleted all of our data, including backups.

Luckily we double checked the deployment before rolling it out on Prod, but it is unacceptable that this issue has been open for more than 5 years and there is still no fix. I've been defending Terraform against my colleagues for its ease of use and cross-provider features, but this issue doesn't help with that.

[majdrezik]

I just ran into this problem.
Any solutions/updates?

[painars]

Workaround that worked for me:

1. Manually modify DB Identifier from AWS Console
2. Comment out aws_db_instance resource or module from your code*
3. Run terraform plan/apply (you will notice that it will think that RDS got deleted so it will update your state file)
4. Uncomment/restore RDS code in your repo and update RDS identifier to new value (that is present in AWS account)
5. Use "terraform import" to move your RDS back to state file
6. Apply terraform code
7. Congratulations! You have successfully changed RDS identifier in AWS Console and Terraform code without recreating instance/losing any data

*sidenote for 2nd point, you will need to adjust any other part of your code it if uses outputs from RDS resource/module.
Luckily for me it was just couple of lambdas and r53 entry that I could just temporarily delete and recreate after RDS with new identifier was back in tfstate file.

[oferreirad]

We can use the parameter identifier to change RDS identifier during RDS creation.

[github-actions]

This functionality has been released in v5.0.0 of the Terraform AWS Provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template. Thank you!

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.