Keep your AWS resources when you rename an AWS CloudFormation stack

Have you ever faced security issues in your organization that required you to change the name of your AWS CloudFormation stack? If so, then you probably know that the only way to change the stack name is to delete the original stack and recreate a new one with the updated name. This task might seem easy enough, until you discover that you still need the resources that were deployed with the original stack. Unfortunately, when you delete a stack, by default you also delete the resources that are included in that stack.

This post describes how to change the name of a CloudFormation stack without deleting the resources that it manages. In the walkthrough, which uses a simple architecture with a single resource, a virtual private cloud (VPC), you add a Retain attribute to the resource’s deletion policy so that the resource isn’t lost when that stack is deleted. After you delete the stack and verify that the resource was retained, you launch another CloudFormation stack with a different name and import the resource. The result is a new stack with a different name from the original (meeting your security guidelines) but with the same resource as the original stack.

In your own templates, required resources might include an Amazon Simple Storage Service (Amazon S3) bucket, Amazon CloudWatch log group, and more. If you need to retain multiple resources such as these, you add a Retain attribute to each resource’s deletion policy.

NOTE: To see a list of resources that are supported for this solution, refer to Resources that support import and drift detection operations. Also note that this solution does not retain events from the original stack. You should always test in a development environment with noncritical resources first to avoid any unexpected data losses.

Overview

Figure 1 shows the overall process of retaining a single resource—in this case, a VPC—when changing the name of a CloudFormation stack using the two templates I provide in this post.

Figure 1: Process overview

1. Launch a CloudFormation stack that deploys a single VPC.
2. Add a Retain attribute to the deletion policy of the VPC deployed by the stack.
3. Delete the stack and verify that the VPC resource is retained.
4. Create a new stack and import the resource that was retained from the original stack. This stack is created with a new name.
5. Remove the Retain attribute from the stack to revert to the original template.

Prerequisites

Before you begin the walkthrough, you must have an AWS account. If you don’t have an account, sign up at https://thinkwithwp.com. You should also have a basic knowledge of AWS CloudFormation.

Before you begin

Navigate to the GitHub repository , and download the following two CloudFormation templates to your local machine.  You will use them later in the “Walkthrough” section.

• Template 1 (01-vpc-basic.yaml) – The template contains the following code and deploys a single VPC.

  AWSTemplateFormatVersion: 2010-09-09
  
  Description: "Deploys a VPC (qs-1t72ibrq5)"
  
  Resources:
    Vpc:
      Type: AWS::EC2::VPC
      Properties:
        CidrBlock: 10.0.0.0/16
        Tags:
          - Key: Name
            Value: rename-stack-demo

• Template 2 (02-vpc-retain.yaml) – This template contains the following code. Notice that it’s exactly the same as template 1, but this one has an added Retain attribute that’s connected to the VPC resource .

  AWSTemplateFormatVersion: 2010-09-09
  
  Description: Deploys a VPC
  
  Resources:
    Vpc:
      Type: AWS::EC2::VPC
      DeletionPolicy: Retain
      Properties:
        CidrBlock: 10.0.0.0/16
        Tags:
          - Key: Name
            Value: rename-stack-demo

Walkthrough

Step 1: Launch the stack from the AWS CloudFormation console

1. Launch the following CloudFormation template directly from the CloudFormation console. This template is the same as template 1 in the “Before you begin” section.
2. On the Create stack page, choose Next.
3. On the Specify stack details page, in the Stack name field, replace the text with original. Choose Next.
4. On the Configure stack options page, choose Next.
5. Choose Create stack, and verify that the status of the stack is CREATE_COMPLETE.

Step 2: Add a Retain attribute to the VPC’s deletion policy

TIP: When working with your own stack that includes multiple resources that need to be retained, use a custom automation script to add the Retain attribute. A script can help expedite the overall process and reduce the possibility of inadvertently missing resources.

1.  In the CloudFormation console, choose Stacks.
2. Choose the stack named original that you launched in the previous procedure.
3. Choose Update.
4. Choose Replace current template > Upload a template file > Choose file.
5. Choose the 02-vpc-retain.yaml (template 2) file that you downloaded in the “Before you begin” section, and choose Next.
6. On the Specify stack details page, choose Next.
7. On the Configure stack options page, choose Next.
8. Choose Update stack.
9. Verify that the stack has been created successfully, and choose Update stack.If you encounter a change set error (see figure 2), ignore it. It indicates that the resources themselves did not change, which is expected behavior.
   

   Figure 2: Change set error

10. Verify that the status of the stack is UPDATE_COMPLETE.

Step 3: Delete the CloudFormation stack and verify that the resource is retained

Delete the stack:

1. In the CloudFormation console, choose Stacks.
2. Choose the stack named original, and then choose Delete.
3. On the Delete original? page, choose Delete stack.
4. Verify that the stack has a DELETE_COMPLETE status.

Verify that the resource was retained:

1. In the Amazon VPC console, under VIRTUAL PRIVATE CLOUD, choose Your VPCs.
2. Verify that the VPC with the rename-stack-demo name is retained.
3. Take note of the VPC ID, as you will need it in a later step. For example, in figure 3, the VPC ID is vpc-06452564543234d0b.
   

   Figure 3: VPC resource was retained after stack deletion

Step 4: Create a new CloudFormation stack and import the VPC resources

1. In the CloudFormation console, choose Stacks > Create stack > With existing resources (import resources), as shown in figure 4.
   

   Figure 4: Import existing resources

2. On the Import overview page, choose Next.
3. Under Specify template, choose Upload a template file > Choose file, and then choose the 02-vpc-retain.yaml (template 2) file that you downloaded in the “Before you begin” section.
4. Choose Next.
5. Under Resources to import (1), enter the VPC ID that you noted earlier in the Identifier value field, and choose Next.
   

   Figure 5: VPC ID in the Identifier value field

6. In the Stack name field, type updated, and then choose Next.
7. Review the changes under the Import overview page and choose Import resources.
8. Verify that the status of the stack is IMPORT_COMPLETE.

Step 5: Remove the Retain attribute from the stack to revert to the original template

1. In the CloudFormation console, choose Stacks, and choose the updated stack.
2. Choose Update.
3. Choose Replace current template > Upload a template file > Choose file, and choose the 01-vpc-basic.yaml (template 1) file that you downloaded in the “Before you begin” section.
4. Choose Next.
5. Under the Specify stack details page, choose Next.
6. Under the Configure stack options page, choose Next.
7. Choose Update stack.
8. Verify that the stack has a status of UPDATE_COMPLETE.

Cleanup

To avoid incurring future charges, delete the CloudFormation stack. For instructions, refer to Deleting a stack on the AWS CloudFormation console.

Conclusion

Now you understand a common workaround for renaming a stack without deleting the resources that it manages. You can extend this solution with other resources such as an Amazon S3 bucket or an Amazon CloudWatch log group.

Keep in mind that this solution does not work for all resources. To see a list of supported resources, refer to Resources that support import and drift detection operations. Also note that this solution does not retain events from the original stack. You should always test in a development environment with noncritical resources first to avoid any unexpected data losses.

About the author