Skip to main content
Welcome to this lesson on AWS CloudFormation resource policies. This practical overview explains the three per-resource policies CloudFormation provides, how they affect resource lifecycle operations (create, update, delete), and when to apply each policy to protect data and manage infrastructure changes safely. At a high level, CloudFormation supports three related per-resource policies:
  • DeletionPolicy — controls what happens to a resource when its stack is deleted.
  • UpdateReplacePolicy — specifies what to do with the old resource when a replacement occurs during a stack update.
  • CreationPolicy — requires external confirmation (a “signal”) before CloudFormation considers a resource creation successful.
Below you’ll find a quick comparison table, detailed explanations, and concise YAML examples for each policy.
PolicyPurposeTypical Use Case
DeletionPolicyDefines action on a resource when its stack is deletedPreserve critical data (Retain) or create snapshots (Snapshot)
UpdateReplacePolicyControls the old resource’s fate when a replacement is needed during updateRetain existing data while creating a new resource
CreationPolicyWaits for resource signals before marking creation successfulEnsure bootstrapping scripts finish on EC2 or Auto Scaling instances

​
DeletionPolicy

The DeletionPolicy attribute tells CloudFormation what to do with a resource when its stack is deleted. Choosing the right deletion behavior helps prevent accidental data loss, or conversely, prevents orphaned resources and unexpected costs. Common values:
  • Delete — CloudFormation deletes the resource (default).
  • Retain — CloudFormation leaves the resource in your account. Use this to protect data but be aware retained resources are unmanaged by CloudFormation and may incur charges.
  • Snapshot — CloudFormation takes a snapshot before deletion. Supported only for snapshot-capable resources (EBS volumes, RDS DB instances, and similar).
Example: retain an Amazon S3 bucket so it isn’t removed when the stack is deleted. 
MyBucket:
  Type: AWS::S3::Bucket
  DeletionPolicy: Retain
  Properties:
    BucketName: my-important-bucket

​
UpdateReplacePolicy

When an update requires a resource replacement (for example, changing an immutable property), CloudFormation creates the replacement resource and then takes action on the old one. UpdateReplacePolicy accepts the same values as DeletionPolicy (Delete, Retain, Snapshot) and controls the behavior applied to the old resource after the new resource has been created. Use UpdateReplacePolicy to avoid accidental data loss during updates by retaining the old resource until you’ve validated the replacement. Example: keep the old S3 bucket when a replacement occurs during stack update. 
MyBucket:
  Type: AWS::S3::Bucket
  UpdateReplacePolicy: Retain
  DeletionPolicy: Retain
  Properties:
    BucketName: my-important-bucket

​
CreationPolicy

CreationPolicy requires confirmation from the resource (a ResourceSignal) before CloudFormation marks the resource creation as successful. This is commonly used with EC2 instances or Auto Scaling groups whose bootstrapping scripts must complete before the stack creation proceeds. Key points:
  • CreationPolicy waits for a specified number of success signals within a timeout period.
  • Signals are typically sent with the CloudFormation helper (cfn-signal) or via API calls.
  • If required signals are not received before the timeout, the creation fails and CloudFormation rolls back (unless rollback is disabled).
Example: require one signal from an EC2 instance within 15 minutes. 
MyInstance:
  Type: AWS::EC2::Instance
  Properties:
    ImageId: ami-0123456789abcdef0
    InstanceType: t3.micro
  CreationPolicy:
    ResourceSignal:
      Count: 1
      Timeout: PT15M

​
Best practices and callouts

Use DeletionPolicy: Retain to protect critical data and resources from accidental stack deletions. Always document and tag retained resources so they can be discovered and managed later.
Avoid using Retain indiscriminately. Retained resources become unmanaged by CloudFormation and can accumulate costs. Plan lifecycle management, automation, or tagging strategies for retained items.

​
Notes and constraints

  • DeletionPolicy and UpdateReplacePolicy are set per resource — not at the stack level.
  • Snapshot is valid only for resource types that support snapshots (EBS, RDS, etc.).
  • CreationPolicy requires that the resource or bootstrapping scripts send a signal (for example, via cfn-signal). Missing signals before timeout cause stack failure/rollback.
  • For Auto Scaling groups, CreationPolicy can wait for signals from instances launched by the group — useful for ensuring instances are healthy and bootstrapped before completing stack creation.
This overview should help you choose the right CloudFormation policy to protect data, control replacements during updates, and ensure resources are properly initialized during stack creation.

Watch Video

Practice Lab