Change sets are CloudFormation's **dry-run primitive**. You submit proposed template/parameter changes; CFN computes a diff against the live stack; you review; you execute or discard. Nothing happens to running resources until you choose to execute. ## The workflow 1. Submit a modified template or parameter values 2. CFN compares submitted state with the current stack and produces a change set (status `CREATE_PENDING` → `CREATE_COMPLETE`) 3. View the change set: which resources will be added / modified / deleted, plus property-level before/after diffs 4. Optionally create more change sets to compare different proposed changes side-by-side 5. Execute one — the rest are discarded automatically (they no longer apply to the updated stack) The point of step 4 is comparison. You can have N change sets open against the same stack, and only one wins. ## What change sets DO NOT validate This is the surprise that bites people. A change set with status `CREATE_COMPLETE` is **not** a guarantee the update will succeed. CFN does not check: - AWS account quotas (e.g., adding a 6th VPC when limit is 5) - IAM permissions to actually modify the resource - Update-incompatible operations the underlying service will reject (e.g., shrinking RDS storage) A "valid" change set can still fail at execute time. When it does, default rollback applies. ## Replacement visibility The most useful thing change sets surface is the `Replacement` flag on each property change. This is your last chance to catch the [[CFN Update Behaviors and the Replacement Trap|replacement trap]] before live data dies. In the AWS CLI output, look for `Replacement: True` in the `ResourceChange.Details` array. In the console, the Changes tab shows replacement explicitly per resource. ## Nested stacks: enabled by default When creating a change set for a stack containing nested stacks, CFN creates change sets for **all** nested stacks by default. To scope to the current stack only, explicitly disable this. In most cases you want the default — partial change sets across a hierarchy hide cross-stack effects. **Caveat**: property-level change sets do not resolve cross-stack references when generated for nested stacks. Resources in a child stack that reference a modified parent's outputs may be marked for **conditional replacement** — actual replacement depends on parent execution. ## When to skip change sets Change sets add a step to every deployment. Skip when: - Stack contains no stateful resources (everything safely re-creatable) - You're certain the change is `No Interruption` only (e.g., tag-only updates) - You're using `update-stack --use-previous-template` for a parameter-only change you've already verified For everything else — especially anything touching RDS, EBS, security groups, IAM — change sets are cheap insurance. ## Related - [[CFN Drift-Aware Change Sets Three-Way Comparison]] - [[CFN Update Behaviors and the Replacement Trap]] - [[CFN Failure Rollback Behavior]]