Discrepancy between CDK and CloudFormation in default DeletionPolicy of various resources

[pierreozoux]

Describe the bug

• In CloudFormation, the default is to delete empty S3 buckets.
  https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-attribute-deletionpolicy.html

• In CDK, the default is to retain s3 buckets:
  https://github.com/awslabs/aws-cdk/blob/7cb8e5e61debd5b1f06293051bbb522f0331fb3c/packages/%40aws-cdk/aws-s3/lib/bucket.ts#L759

I see 2 confusing things here:

• DeletionPolicy vs RemovalPolicy why using a different vocabulary?
• having a different behavior between CloudFormation and CDK

I think it is a bug, but you might argue it is a feature.
I'd like to understand the logic to be the least surprised when using the CDK.

Thanks!

[RomainMuller]

DeletionPolicy vs RemovalPolicy why using a different vocabulary?

I do not know of the reasoning behind the removalPolicy name, and barring other items that I am not aware of, I would agree that it should be called deletionPolicy.

---

having a different behavior between CloudFormation and CDK

The CDK behavior was introduced after complaints that the buckets wouldn't be deleted if they aren't empty (causing stack delete failures). So the default CDK behavior is to not attempt to delete S3 buckets. I agree this is an outlier in how this differs from the standard CFN behavior.

---

With respects to this being a bug versus feature... There is a thin line and this could sit right on it. I'd lean to it being a feature request more than a bug, because the current behavior is intentional (even though one can think of it as surprising).

[kevin-lindsay-1]

@RomainMuller I agree the line is rather thin on this particular issue. Personally, I generally lean towards setup/teardown approaches myself, and my personal preference on the default behavior would be to delete the items in the bucket, and then delete the bucket.

Such a behavior is probably due to a limitation from CFN, however from a consistency standpoint I'd argue if the default behavior of almost anything else in the CDK is to have a removalPolicy of Destroy, and this behavior was originally worked around in the instance of S3 due to deletion failures, it would be preferable for the same behavior to be expected.

I encountered this behavior a few days ago while testing out setup/teardown, and noticed a bunch of orphaned buckets, which led me to this issue because specifying Destroy on a bucket doesn't actually destroy it, because the default behavior appears to be overridden.

For example, even when I specify:

new s3.Bucket(this, 'TestBucket', {
  removalPolicy: cdk.RemovalPolicy.Destroy
});

The bucket is not destroyed, and upon stack deletion, the event log shows DELETE_SKIPPED for this particular resource, which I would classify as a bug.

[dz902]

Not only S3, LogGroup is the same. It seems all resources are default to retain. Not only DeletionPolicy, but also UpdatePolicy.

This is very bad as currently there is only very hacky way to specify DeletionPolicy. This really ought to be fixed.

[dz902]

Also this naming thing is so inconsistent and desperate.

DeletionPolicy vs. RemovalPolicy? Fine...but why the value for RemovalPolicy is "Destroy" other than "Remove"?

[skinny85]

For example, even when I specify:

new s3.Bucket(this, 'TestBucket', {
  removalPolicy: cdk.RemovalPolicy.Destroy
});

The bucket is not destroyed, and upon stack deletion, the event log shows DELETE_SKIPPED for this particular resource, which I would classify as a bug.

Did you run cdk deploy to change this before doing the delete?

I'm using this functionality quite often myself, and I've never had any issues with it working.

[skinny85]

DeletionPolicy vs. RemovalPolicy? Fine...but why the value for RemovalPolicy is "Destroy" other than "Remove"?

Because "Remove" could suggest it's just removed from the template. "Destroy" makes it clear the resource is actually torn down.

[justin8]

Then call it a destruction policy?

The original name of "deletion policy" is definitely clearer than "removal policy", and would've solved this issue without making it confusing.

[eladb]

Related to Stateful Resources