Deleting your AWS Copilot stacks can delete your database. Here’s why.

Description and use

Deleting AWS Copilot stacks without setting retain policies destroys certificates, DNS records, load balancers, and databases. By applying DeletionPolicy: Retain to all resources, importing them into Terraform, and then deleting the Copilot stacks, the infrastructure can be migrated safely.

Problem

Deleting Copilot stacks naively can destroy production resources such as certificates, DNS records, load balancers, file systems, and databases.

Outcome

Using ecsodus to apply retain policies and import resources, a real Copilot v1.34.1 app with 5 stacks and 49 resources was migrated to Terraform without any resource loss; all services remained operational.

Workflow

• 1. Apply DeletionPolicy: Retain and UpdateReplacePolicy: Retain to every resource in all stacks, nested stacks, and StackSets. 2. Import all resources into Terraform with exact current values. 3. Delete the Copilot stacks; CloudFormation forgets the resources and nothing is deleted.

Evidence

Copilot ships 13 Lambda-backed custom resources, and 9 of them do something destructive on Delete.

Source

Each service stack carries an EnvControllerAction custom resource. When the last service that needs a shared ALB, NAT gateways or EFS is deleted, the env-controller updates the environment stack and removes them.

Source

Aurora, DynamoDB and S3 addons live in a nested stack with no DeletionPolicy. Delete the parent and CloudFormation deletes your database.

Source

The safe sequence is: Put DeletionPolicy: Retain and UpdateReplacePolicy: Retain on every resource in every stack, nested stacks and the StackSet included.

Source

On September 30 I ran it end to end against a real Copilot v1.34.1 app (an environment, a Load Balanced Web Service, DynamoDB and S3 addons; 5 stacks, 49 resources) in a sandbox account: 44 of 44 resources imported, 0 changed, 0 destroyed.

Source