Open jgondron opened 5 years ago
It aligns with CloudFormation behaviour. Why make it dis-aligned?
Note The AWS CDK's RemovalPolicy translates to AWS CloudFormation's DeletionPolicy, but the default in AWS CDK is to retain the data, which is the opposite of the AWS CloudFormation default.
:rocket: Feature Request
General Information
Description
The default removalPolicy for resources that have this property is to orphan the resource. Users who are accustomed to using CloudFormation and are used to a "try to delete, then manually resolve any delete issues" may be caught unaware of this behavior. I understand the reasoning behind using this as a default within cdk, but if a user is unaware of this it can cause orphaned resources that cost $.
Proposed Solution
I see two options here, but am not sure of which is most feasible within cdk:
RemovalPolicy.RETAIN
that will be orphaned by the changeset and prompt the user to continue (similar to IAM changes).Environment
Other information
Here's a recent example that I've hit. If a user creates a new CodePipeline:
This will, by default, create a new S3 bucket for it's artifacts and a Customer Managed KMS key to use for encryption. If the user sees this and decides to use an existing managed key instead, they have to explicitly create the bucket and specify the key:
On the next deploy, CloudFormation will create a new S3 bucket referencing the existing key, but will skip deleting the old bucket and KMS key. Unless the user watches closely for
DELETE_SKIPPED
from the CloudFormation events, the user will be unaware of what happened, leaving resources that can accumulate cost over time.