Package: renovosolutions.aws-cdk-aws-organization
cdk-library-aws-organizationThis CDK library is a WIP and not ready for production use.Key challenges with OrganizationsAccounts aren't like AWS resources and theremoval process isn't a simple delete. Therefore the constructs contained in this library donothave the goal to delete accounts.CloudFormation doesn't support Organizations directly so the constructs in this library use CloudFormation custom resources that utilize Python andBoto3Testing the custom provider code with SAM CLIPre-reqsYou will either want a previously created test account or allow the tests to create a new accountTestingCreate a test project that utilizes this library (you can use a development version by utilizingyarn link, but note you might need to set a static dependency for CDK versions orconstructsin the local app or you'll get errors about mismatched object types)Create a test stackSynthesize the test stack withcdk synth --no-staging > template.ymlGet the handler function names from the templateRunsam local start-lambda -t template.ymlRun thehandler_testspython files withpytestlike follows:TEST_ACCOUNT_NAME='<name>' TEST_ACCOUNT_EMAIL='<email>' TEST_ACCOUNT_ORIGINAL_OU='<original ou id>' ACCOUNT_LAMBDA_FUNCTION_NAME='<name you noted earlier>' OU_LAMBDA_FUNCTION_NAME='<name you noted earlier>' pytest ./handler_tests/<test file name>.py -rA --capture=sysUsing the name, email, and original OU env variables here allows the test suite to re-use a single test account. Given deleting accounts is not simple you likely dont want to randomly create a new account every time you run tests.Thetest.pyalso looks up the root org id to run tests so you'll need to have AWS creds set up to accomodate that behavior.You can run the provided tests against the real lambda function by getting the deployed function name from AWS and setting theRUN_LOCALLYenv variableTEST_ACCOUNT_NAME='<name>' TEST_ACCOUNT_EMAIL='<email>' TEST_ACCOUNT_ORIGINAL_OU='<original ou id>' RUN_LOCALLY='false' ACCOUNT_LAMBDA_FUNCTION_NAME='<name you noted earlier>' OU_LAMBDA_FUNCTION_NAME='<name from AWS>' pytest ./handler_tests/<test file name>.py -rA --capture=sysWhy can't I move an OU?Moving OUs isn't supported by Organizations and would cause significant issues with keeping track of OUs in the CDK. Imagine a scenario like below:You have an ou,OUAdmin, and it has 2 children,OUChild1 and Account1, that are also managed by the CDK stack.You change the parent ofOUAdmintoOUFoo. The CDK would need to take the following actions:Create a newOUunderOUFoowith the nameOUAdminMove all of the originalOUAdminOU's children to the newOUAdminDelete the oldOUAdminUpdate all physical resource IDsIt would succeed at moving accounts because physical IDs should not change. Accounting moving between OUs is supported by OrganizationsIt would fail at moving any child OUs because they would also be recreated. Resulting in a change to physical resource ID. Because the custom resource can only managed the resource it's currently acting on,OUAdmin, any children OUs would be "lost" in this process and ugly to try and manage.The best way to move OUs would be to add additional OUs to your org then move any accounts as needed then proceed to delete the OUs, like so:Add new OU resourcesDeploy the stackChange account parentsDeploy the stackRemove old OU resourcesDeploy the stack