4 ms·

You can set the DeletionPolicy attribute to "Retain" to work around this S3 issue. CloudFormation will successfully rollback without attempting to remove the S3

• cle 8y ago
  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.
  • SanderKnape 8y ago
    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.
    • cle 8y ago
      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.
  • deleted 8y ago
    [deleted]