Make create organization idempotent

akefirad commented 3 years ago

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.

fbouteruche commented 3 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:

import an existing organization if one already exists in the account you are deploying the stack to
remove the organization when you delete the stack instead of trying to delete it to avoid deletion failure

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.

akefirad commented 3 years ago

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.

fbouteruche commented 3 years ago

Hello. First of all, I wish you happy new year! We have decided to add this issue in our roadmap.

SmartassSkeleton commented 3 years ago

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 :)

excavador commented 3 years ago

Any updates?

tullie commented 2 years ago

+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.

jeromevdl commented 2 years ago

Hey,

Just started working on this. Keeping the existing organization is one thing but this is just the basis for multiple resources:

CloudTrail trail: a new trail is created (but will fail if already exist with same name) => what is expected?
OUs and accounts: bootstrap kit creates a hierarchy (SDLC, Shared, Prod) and accounts, you may have existing OUs and accounts. Specifying OUs and accounts in AwsOrganizationsStackProps means they will be created (as of now) and thus will fail (for the existing ones) => what is expected?
AWS Config is set up, but cannot be setup if already done in the existing organization => what is expected?

Open for discussion @akefirad @flochaz @tullie

flochaz commented 2 years ago

I see 2 options:

Same logic as the one for org for each resource you mention : if exists don't create and continue (but add Warning log)
Add a parameter to AWSBootstrapKitLandingZoneStage and attributes to nestedOU Params to be able to specify a flag such as 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.

jeromevdl commented 2 years ago

For the organization, as there is only one, if it exists already, we reuse it, no need to specify the organizationId.
For the accounts, I'm adding a 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)
For the OUs, we cannot move them, so specifying a 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?

awslabs / aws-bootstrap-kit

Make create organization idempotent #13