I am building an app with CDK (js) and CloudFormation. I'm using the CfnCollection construct to stand up the OpenSearch Serverless Collection. Everything works fine, but every so often when deploying my app I receive the following error:
ServerlessSearchStack AWS::OpenSearchServerless::Collection UPDATE_FAILED CloudFormation cannot update a stack when a custom-named resource requires replacing. Rename e1jd2h514ya7a8m11234 and update the stack again.
Some research tells me that sometimes resources need replacing, and CloudFormation cannot do this if a custom name was used for that resource. So my initial thought is ok, I will not give my collection a custom name, but CDK requires a name to instantiate a collection. So that does not appear to be an option.
This error gets my app in a state where I cannot deploy without deleting the OpenSearch Serverless Collection, which deletes all data. Furthermore, I have other stacks that are dependent on that OpenSearch Collection, so those in turn need to be deleted first. This is clearly very disruptive and not tenable in the long run. It causes serious down time for my app. I came across this article on CloudFormation needing to replace resources but it isn't particularly helpful.
What causes my AWS OpenSearch Serverless Collection to need replacing? How can I avoid this? I am wondering if the configs of my dependent stacks are triggering a replacement. However, lately it has been needing to be replaced seemingly without any CloudFormation or infrastructure changes whatsoever. Could it have something to do with updating roles? But again, even when I seemingly change nothing it just decides it needs replacing.
How can remedy this error without completely tearing down my app's stacks and rebuilding? This causes serious downtime for my app. One way I have tried is renaming the collection name in code and sometimes that works, but it does result in all data being loss.
Is it possible CDK could be updated to not require the name property when instantiating a collection? Would that help prevent the data loss and CloudFormation would be able to do the replacement on its own?
AWS OFFICIALUpdated 2 years ago
Thank You Mike A! I have confirmed it was a changing of the
Tagsthat was triggering a replacement. We have automated releases which were bumping aversiontag. I am going to remove theversiontagging of the Serverless Collection.