You are designing a CloudFormation template for a production RDS database. How do you configure DeletionPolicy, UpdateReplacePolicy, and stack termination protection to prevent accidental data loss during stack operations?
Quick Answer
Set `DeletionPolicy: Snapshot` (creates a final snapshot before deletion), `UpdateReplacePolicy: Snapshot` (snapshots before replacement during updates), enable stack termination protection, use stack policies to deny Replace/Delete on the database resource, and store the master password in Secrets Manager with dynamic references.
Detailed Answer
DeletionPolicy
DeletionPolicy controls what happens to a resource when it's removed from the template or the stack is deleted. Three options: Delete (default, destroys the resource), Retain (keeps the resource but removes it from CloudFormation management), and Snapshot (creates a final snapshot before deletion, only supported by RDS, EBS, ElastiCache, Neptune, Redshift). For production databases, always use Snapshot at minimum, or Retain if you never want CloudFormation to delete the instance.
UpdateReplacePolicy
Some updates require CloudFormation to replace the resource (create new, delete old). For example, changing an RDS instance's engine version might trigger replacement. UpdateReplacePolicy controls what happens to the OLD resource during replacement. Setting it to Snapshot creates a backup before the old instance is deleted. Without this, an update that triggers replacement silently deletes your production database. This is one of the most dangerous CloudFormation behaviors.
Defense in Depth
Layer multiple protections: (1) DeletionPolicy on the resource, (2) UpdateReplacePolicy on the resource, (3) Stack termination protection on the stack (prevents delete-stack), (4) Stack policies that deny Replace/Delete operations on the database, (5) RDS DeletionProtection at the AWS API level, (6) IAM/SCP policies restricting who can disable these protections. No single layer is sufficient - each protects against different failure modes.
Secrets Management
Never hardcode database passwords in CloudFormation templates. Use dynamic references to Secrets Manager: {{resolve:secretsmanager:prod/db-password:SecretString:password}}. CloudFormation resolves this at deploy time and never stores the plaintext value in the template or state. Combine with Secrets Manager rotation for automatic password rotation.