Deleting your AWS Copilot stacks can delete your database. Here’s why.
说明与用途
在未设置保留策略的情况下删除 AWS Copilot 堆栈会导致证书、DNS 记录、负载均衡器和数据库被销毁。通过为所有资源设置 DeletionPolicy: Retain、将其导入 Terraform,然后删除 Copilot 堆栈,可以安全迁移基础设施。
问题
Deleting Copilot stacks naively can destroy production resources such as certificates, DNS records, load balancers, file systems, and databases.
结果
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.
工作流
- 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.
证据
Copilot ships 13 Lambda-backed custom resources, and 9 of them do something destructive on Delete.
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.
Aurora, DynamoDB and S3 addons live in a nested stack with no DeletionPolicy. Delete the parent and CloudFormation deletes your database.
The safe sequence is: Put DeletionPolicy: Retain and UpdateReplacePolicy: Retain on every resource in every stack, nested stacks and the StackSet included.
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.
- 记录日期: 2026-10-01T04:08:00.418Z