aws / aws-cdk

The AWS Cloud Development Kit is a framework for defining cloud infrastructure in code

Home Page:https://aws.amazon.com/cdk

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

(core): import automatically resources like cloudwatch/s3,etc there were part of CDK stack/cloudformation before deletion

argenstijn opened this issue · comments

Describe the feature

If you have a CDK stack with for example a S3 bucket or cloudwatch loggroup and you remove the CDK stack and S3 contains one or more files the S3 bucket is not destroyed (or the cloudwatch log group). If you redeploy your stack it will complain that S3 or cloudwatch loggroup already exist. This is a known issue/feature.

What i want is that once you redeploy the CDK stack it will automatically reconigize that the S3 bucket and/or cloudwatch log group is a part of the CDK stack and will automatically add this to the stack. Then it will make sure it contains the correct settings,etc. Maybe by introducing extra meta-data on the S3 or cloudwatch group you can achieve something like this.

I think this is one of the most common problems i face today with CDK. I have to manually delete the cloudwatch loggroup and it's not possible to retain the events (yes, you can make a backup to s3 but you cannot create a bacukup,delete the old group, create the new group and import all the old events back!).

Any ideas if something like this is possible to do in CDK?

Use Case

-> Manual task
-> Frustrating if you forget
-> Need access to production environment to fix things
-> Hard to maintain the cloudwatch log events

Proposed Solution

No response

Other Information

No response

Acknowledgements

  • I may be able to implement this feature request
  • This feature might incur a breaking change

CDK version used

2.141.0 (build 3d1c06e)

Environment details (OS name and version, etc.)

Windows 10/ Linux

@argenstijn , thanks for reaching out.

I am highly doubtful if this would be a good idea, to keep the metadata about stack in the resources like S3, because it will increase overhead in the resource metadata. It might lead to error in usability of resources across multiple stacks as it would be difficult to decide which stack created which resource and where its currently used.

Having this feature might complicate many scenarios. but we are open to feedback/inputs from the community.

So, we don't keep stateful information about the history of you stack but something we are looking into is enabling the ability to auto-import named resources now that CloudFormation has enabled this functionality on their end. I'm not exactly sure when we'll get this implemented but I'll update here when I know more.