Hacker News Reader

You better do so before deploying again, because the roll forward will break since the resource already exists.

This a major pitfall when using DeletionPolicy=Retain with named resources. It breaks seamless rollbacks/rollforwards. If you rollback, in order to deploy again you need to either delete the named resources with DeletionPolicy=retain that were rolled back, or update your template to rename them all. It is such a huge pain.

View on HN

True, but it beats the alternative where CloudFormation deletes objects that you didn't want deleted. The underlying issue is that the S3 objects are outside of the CloudFormation scope, thus it takes no risk and doesn't delete your objects.

A nice feature would be a "ForceDelete" deletionpolicy where it would delete the objects. You can even set this initially when creating a stack, and change it to "Retain" later when the stack is stable.

Totally agree btw that it's a huge pain initially, though once you know it it's also not that hard to work around.

My preferred behavior would be for CFN to not barf when rolling forward. In other words, to be able to assume control over a resource that already exists.

Reply on news.ycombinator.com