Feature Request: Dry-Run (Preview) Mode for CloudFormation deployments

### Resource Name

_No response_

### Details

**Problem**

Currently there is no built-in “dry-run” or full simulation mode in CloudFormation. The best you can do is create a ChangeSet and inspect it, but it doesn't catch all issues. ChangeSets do list which resources will be created/updated/replaced/deleted, but they don’t guarantee success at deploy time. For example, if a ChangeSet would add a resource whose name already exists in the account, the update will fail even though the preview showed it as “Add” because CloudFormation creates all new resources before deleting any removed ones (see #2365) so a duplicate name causes an error. In practice this means hidden conflicts (like two ElastiCache users or an existing App-AutoScaling policy) only surface at execution time, and there is no way to detect them beforehand.

Managing this without a `dry-run` is painful at scale. With dozens of stacks or multiple customers/environments, teams must remember every naming rule and unique resource in each AWS account. For instance, AWS best practices encourage separate dev/test/prod accounts so you can test changes safely, but many companies still deploy multiple stacks in one account. In a single-account setup a new resource name conflict could break a stack update, whereas in multi-account pipelines (with isolated environments) it would not. Having to memorize each stack’s resources (or write custom checks) is not feasible and slows down CI/CD. In short, even though ChangeSets provide a preview, they leave critical gaps. As one answer on StackOverflow put it, the only workaround today is to use mock testing (Moto) – “which cannot 100% guarantee you won’t encounter any errors.”

**Proposed Solution**

We request a new CloudFormation feature (CLI/API and/or console) – e.g. a --dry-run flag on the deploy/update commands – that performs a full preview of the deployment without making changes. This dry-run mode would invoke ChangeSets behind the scenes and then report the intended actions (resource-level changes and property diffs) exactly as a real deployment would, but stop short of executing them. In other words, the CLI could automatically run CreateChangeSet + DescribeChangeSet (including all available details like before/after values) and then either clean up the ChangeSet or simply not execute it. The output would be a detailed plan of the update. Ideally, this mode would also surface any execution-time errors it can detect. For example, if a resource name is already in use or a quota would be exceeded and fail the dry-run with a clear message. In practice it would work much like Terraform’s plan or other IaC tools’ check modes: integrate with existing ChangeSet functionality (so it does not replace ChangeSets, just automates them) and provide an easy way to review or gate CI/CD pipelines.
- CLI integration: For example, a command like `aws cloudformation deploy --dry-run` or `update-stack --dry-run` could create the ChangeSet and print all of its changes (including property diff) in human- and machine-readable form, then delete the ChangeSet. Incorporating this into CDK, and adding a similar flag in the CloudFormation console (“Preview only, do not execute”) would also be useful.
- Pipeline use case: In CI/CD (CDK Pipelines, CodePipeline, Jenkins, etc.) this would serve as a pre-deploy validation step. One could add a Plan stage that runs `cloudformation deploy --dry-run` and fails if there are errors or unexpected changes, before any production rollout. This would shorten feedback loops and prevent simple mistakes (typos in names, bad parameter values, etc.) from breaking deployments.
- Incremental improvement: AWS has already enhanced ChangeSets (e.g. showing before-and-after values for changed properties, and even resolving some references during preview ), which is helpful for visibility. A formal dry-run option would build on these features and remove the need for manual scripts or external tools.

**TLDR**

A native dry-run mode would catch many classes of errors early. Teams would no longer have to manually memorize stack details or rely on ad-hoc mocks. For example, it would explicitly warn if an update will create an ElastiCache user whose name already exists, instead of surprising you with a CREATE_FAILED at deploy time. This greatly reduces deployment risk and (potential) downtime. It also aligns with CloudFormation best practices of testing across environments, but makes it safer even when using fewer accounts.

**References**
1. [Dry run for CloudFormation update (StackOverflow)](https://stackoverflow.com/questions/61335288/dry-run-for-cloudformation-update)
2. [Is there a way to unit test AWS CloudFormation template (StackOverflow)](https://stackoverflow.com/questions/40299413/is-there-a-way-to-unit-test-aws-cloudformation-template)
3. [A Simple Introduction to AWS CloudFormation Part 4 – Change Sets = Dry Run Mode (BoltOps Blog)](https://blog.boltops.com/2017/04/07/a-simple-introduction-to-aws-cloudformation-part-4-change-sets-dry-run-mode)
4. [AWS CloudFormation Dry Run with Lono cfn preview (Medium)](https://medium.com/boltops/aws-cloudformation-dry-run-with-lono-cfn-plan-2a1e0f80d13c)
5. [Change Sets for AWS CloudFormation (AWS Blog)](https://aws.amazon.com/blogs/aws/new-change-sets-for-aws-cloudformation/)
6. [CloudFormation Change Sets – Review Changes Before Update (CuriousOrbit Blog)](https://curiousorbit.com/blog/cloudformation-changeset/)
7. [CloudFormation Stack & Change Set Best Practices (Reddit)](https://www.reddit.com/r/aws/comments/vix80r/cloudformation_stack_change_set_best_practices/)
8. [CloudFormation Change Sets Archives (Jayendra Patil Blog)](https://jayendrapatil.com/tag/cloudformation-change-sets/)
9. [Allow re-generating CloudFormation changeset after failure (AWS CDK GitHub Issue)](https://github.com/aws/aws-cdk/issues/11995)
10. [Offer dry run option for cdk destroy](https://github.com/aws/aws-cdk/issues/30972)

The issue names no repository files, tests, or implementation entry points; it requests a new CloudFormation CLI/API and console capability. Start by checking whether this repository accepts coverage requests rather than code changes; done would require a maintainer-defined implementation scope and an AWS service decision on dry-run behavior.

Written by the indexing model from the issue text.