Closed akefirad closed 2 years ago
Thanks for your feedback.
You are right. As of today, only one organization can be created per account and one organization has only one management account.
So, if I understand well, you would like to:
Am I right?
Considering the import of an existing organization, should we also support importing existing organization units and accounts?
We are glad of your request as we were waiting for customer feedback to go further on that path to be sure to fit customer needs.
Thanks for the reply. That's right.
As of today, only one organization can be created per account and one organization has only one management account.
Considering changing this by AWS leads to a breaking change, I'd say it's safe to proceed with the assumption.
Am I right?
Absolutely!
Considering the import of an existing organization, should we also support importing existing organization units and accounts?
I'd say yes, but only those that are asked to create/import in the AwsOrganizationsStackProps
object.
We are glad of your request as we were waiting for customer feedback to go further on that path to be sure to fit customer needs.
That's much appreciated. As a general feedback, I'd suggest to drop the idea of "only suitable for users with a clean AWS account". I don't think this is practical. I don't have statistics, my guess is if someone has a clean AWS account, most probably they have neither time nor the need to play by the book.
Let me know if you need help with anything.
Hello. First of all, I wish you happy new year! We have decided to add this issue in our roadmap.
This is an issue that me and the company I work for are dealing with at the moment too. I'd like to +1 the demand for this issue :)
Any updates?
+1 on this, i'm running into errors trying to redeploy this stack because I have a CCID organization and I can't find a way to delete it. If this stack would skip creating that the CCID account when it already exists they'd be no problems.
Hey,
Just started working on this. Keeping the existing organization is one thing but this is just the basis for multiple resources:
AwsOrganizationsStackProps
means they will be created (as of now) and thus will fail (for the existing ones) => what is expected?Open for discussion @akefirad @flochaz @tullie
I see 2 options:
useExisting
or capability to give the ID of the resource to reuse organizationId
, accountId
etc. that would let the user capable of re organize it's own resources as part of the bootstrap kit.organizationId
.reuseAccountId
flag in the nestedOU params, so that we can take the existing account and move it to the good OU (accounts are moved anyway, from root to target OU, now it will be from the source OU to the target OU, except if target==source)reuseOuId
is not really feasible: Indeed, if the target OU tree is different from the source, we won't be able to reuse one OU elsewhere in the tree. So in that case, I create the target tree (nestedOU) and if an OU already exist at the same place (same name and same parent), I reuse it.That way we can do things like this:
Root Root
|- OU Dev |- OU SDLC (new)
| |- Account ProjectA | |- OU Dev (new, because new parent)
| |- Account ProjectB | |- Account ProjectA (moved)
|- OU Shared | |- Account ProjectB (moved)
| |- Account CICD ==> (reuse all accounts) ==> |- OU Shared (reuse)
|- OU Prod | |- Account CICD (don't move)
|- Account ProjectA |- OU Prod (reuse)
|- Account ProjectB | |- Account ProjectA (don't move)
| |- Account ProjectB (don't move)
|- OU Dev (remains from source, with no account, up to you to remove it)
Still need to figure out what to do with config and cloudtrail but what do you think of the above solution for the org?
My understanding is that there can be only one organization (in each account) and since there's only one master/management account for the whole setup, we can say there is only one organization for this setup.
Now the question is, can we refactor the
create-organization
part in a way that, if the organization exists, it simply skip it (instead of failing). This way by deploying the stack for the first time, the existing organization becomes part of the stack.The value of such feature is to let people with existing organization use this library.
My understanding is, this requires a custom lambda (instead of using the
AwsCustomResource
feature of CDK). On that note, I also suggest to change the deletion logic to just remove the resource from the stack instead of trying to delete it. For all practical purposes, it's not possible to easily delete the organization (because of delay in deleting accounts). In addition to the above, users can easily drop the stack and start over, if needed.Happy to help with this, since it's a blocker for us.