Best practice guidance to avoid "CloudFormation cannot update a stack when a custom-named resource requires replacing"



Over the years we have taken the approach of naming everything we deploy — it's clean, orderly and unambiguous.

Since embracing infastructure-as-code practices, our CloudFormation recipes have been written to name everything with the project's prefix and stage. For example, a VPC will be deployed as projectname-vpc-dev, and its subnets will be projectname-subnet-a-dev, etc.

Unfortunately, it seems some AWS resources won't update via CF if they are named — CloudFormation returns an error like this:

CloudFormation cannot update a stack when a custom-named resource requires replacing. Rename <name> and update the stack again.

How should we best overcome this? Should we simply avoid naming things? Can we use tags instead to avoid this? What's best practice?

For reference, here's a snippet of CloudFormation that appears to be causing the issue above (with serverless.yml variables):

Type: AWS::EC2::SecurityGroup
  GroupName: projectname-dev
  GroupDescription: Security group for projectname-dev

I also had the same problem previously with AWS::RDS::DBCluster for DBClusterIdentifier.

Generally speaking, how do I know which CloudFormation settings block stack updates like this? It feels like a bit of whack-a-mole at present. For the above example the docs at say nothing of this behaviour, but it does say "update requires replacement" against the fields GroupName and GroupDescription. Is that what I need to look out for, or is that something different again?

Thanks in advance... Scott

asked 2 years ago9269 views
2 Answers

Hi there!

From the notes, I understand that you are getting an error “CloudFormation cannot update a stack when a custom-named resource requires replacing”, while trying to updating an existing stack. Please correct me if I misunderstood.

Please note that this error typically occurs when a stack update tries to replace resources that have properties with custom names. AWS CloudFormation doesn't replace a resource that has a custom name unless that custom name is changed to a different name. I understand that in your case, you have been naming everything with the project's prefix and stage. Nonetheless, you can still use that method with slight changes.

This is how you can resolve the issue:

  1. In a code editor, open the AWS CloudFormation template for the stack that you want to update.
  2. Replace the names, or values, of any resource properties that have custom names with different names. You can refer to [1] on naming your resources.
  3. Save the changes to your AWS CloudFormation template, and then use the template to update your stack, you can check [2] on updating stacks directly.

In your case on step 2, you can change from e.g. projectname-dev to projectname-dev1. Another method is to omit the DBInstanceIdentifier property from your template. However, in this case AWS CloudFormation will generate a unique physical ID to use for the DB instance.

To prevent a stack failure and avoid the error message, change any resources with custom names to use different names before you update a stack.

I hope you find the above information helpful. Have a great day ahead!


[1] [2]

answered 2 years ago
profile picture
reviewed 2 months ago

Hi Scott

I appreciate the need to adopt a nomenclature standard for resources as that certainly helps with administration. Having worked a lot with nomenclature standards for public cloud resources and implementing them via Terraform, it's regressive to have to change custom resource names before updating CloudFormation stacks. Now, given that AWS uses tags even when naming some resources (e.g. VPC, EC2 instance) by using a tag with Key=Name, I recommend using **tags ** for naming all resources (whether implicitly done for resources such as VPC or needed explicity for resources such as EC2 security groups). Using tags to implement a nomenclature standard for your AWS resources will help you avoid such issues with CloudFormation.

So, for your example, you may omit GroupName from the CloudFormation template (it's not required) and instead use Tags (Name=projectname-dev). When you do this, your security group name will be a combination of your stack name, LogicalID for the resource and a random string, but your tag Name=projectname-dev will be assigned to the security group and may be used for your administration.

answered a year ago
profile picture
reviewed 2 months ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions