Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[core] Support importing existing orphaned resources to CloudFormation stacks #9686

Closed
kennu opened this issue Aug 13, 2020 · 5 comments
Closed
Assignees
Labels
@aws-cdk/core Related to core CDK functionality feature-request A feature should be added or improved. needs-triage This issue or PR still needs to be triaged.

Comments

@kennu
Copy link

kennu commented Aug 13, 2020

CloudFormation has support for importing existing resources into a stack. You can use the ResourcesToImport parameter to createChangeSet to do it.

Could AWS CDK support importing existing resources? The current implementation that calls createChangeSet does not seem to pass the ResourcesToImport parameter in any situation.

I tried to search for existing issues about this. They are hard to find because many issues talk about importing exported values or importing a reference to a resource in another stack. But here I mean importing orphaned cloud resources.

Use Case

Typical use cases are:

  • Moving resources from one CloudFormation stack to another
  • Splitting CloudFormation stacks when they become too big
  • Adopting an orphaned resource because a stack was broken and had to be deleted
  • Adopting a resource that was created manually before CloudFormation supported the resource type

These use cases are important when the orphaned resource contains data, e.g. a DynamoDB table or a S3 bucket that cannot be deleted.

Proposed Solution

I am not sure about all the details that are related using to ResourcesToImport. It probably requires a lot of testing with different AWS resource types to make it work.

In a perfect world AWS CDK would automatically import named resources when it notices that the resource already exists outside the stack. It would ask the user for confirmation if there are any issues, like having to tune the resource policy/permissions/properties to make the import work.


This is a 🚀 Feature Request

@kennu kennu added feature-request A feature should be added or improved. needs-triage This issue or PR still needs to be triaged. labels Aug 13, 2020
@github-actions github-actions bot added the @aws-cdk/core Related to core CDK functionality label Aug 13, 2020
@ghost
Copy link

ghost commented Aug 14, 2020

There are ways to use existing resources in CDK apps. See the Resources topic in the Developer Guide. Does that help?

@kennu
Copy link
Author

kennu commented Aug 14, 2020

@jerry-aws No. Like I said in the issue description, I'm not talking about referring to external resources. I'm talking about importing orphaned resources back into a CloudFormation stack so that CloudFormation actually takes ownership of the resource. CloudFormation supports this, so I think AWS CDK could support it too.

@NetaNir
Copy link
Contributor

NetaNir commented Aug 16, 2020

We are tracking this in the RFC repo, see aws/aws-cdk-rfcs#52. Closing this in favor of the RFC issues.

@hugomallet
Copy link

hugomallet commented Sep 10, 2020

Is there any workaround to reattach an orphaned s3 to cdk stack ?
Because fromBucketArn doesn't allow to modify an existing s3 bucket, i am facing a deadlock ...

@jaecktec
Copy link

@hugomallet when you create a new stack you can import resources.
For that 'synth' your stack and when creating you chose 'with existing resources'

however you maybe need to add some additional parameters like 'retention' to the resources. (the cloud-formation import is so nice to prompt you why it failed)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
@aws-cdk/core Related to core CDK functionality feature-request A feature should be added or improved. needs-triage This issue or PR still needs to be triaged.
Projects
None yet
Development

No branches or pull requests

5 participants