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.

Источник