Recently came across this video from AWS https://www.youtube.com/watch?v=-n65I4M8cas
It provides some updates from AWS regarding enabling AWS Control Tower on Existing Organisation, thus saving you time from having to set up a new Tenancy and migrating the AWS Accounts from the old Org to the new.
Unfortunately this video missed some key information regarding prepping your Organisation and Accounts for Control tower, so figured I’d add a blog to help others out who may be stumbling on these points.
Existing Org Prep
The primary doc link for info about Enabling AWS Control tower on an existing org is here: https://docs.aws.amazon.com/controltower/latest/userguide/existing-orgs.html
This documentation says the following:
- You can have one landing zone per AWS Organizations organization.
- AWS Control Tower uses the management account from your existing AWS Organizations organization as its management account. No new management account is needed.
- AWS Control Tower sets up two new accounts in a registered OU: an audit account and a logging account.
- Your organization’s service limits must allow for the creation of these two additional accounts.
- After you’ve launched your landing zone or registered an OU, AWS Control Tower guardrails apply automatically to all enrolled accounts in that OU.
- You can Enroll additional existing AWS accounts into an OU that’s governed by AWS Control Tower, so that guardrails apply to those accounts.
- You can add more OUs in AWS Control Tower and you can Register existing OUs.
So the key take aways are:
- You need to check your service limits
- You need emails for 2 new accounts that will be vended & MFA tokens for their root account lock down
- You will need to register existing OUs after Control Tower has been deployed (so Post activity)
adding in that you will need your org to have all features enabled for things like: Enable trust access with AWS Organizations for AWS CloudFormation StackSets which is useful in a Landing Zone tenancy.
Be mindful of the following regarding AWS SSO:
- AWS Control Tower does not delete an existing AWS SSO configuration.
- If AWS SSO is already enabled, and if you are using SSO Directory, AWS Control Tower adds resources such as permission sets, groups, and so forth, and proceeds as usual.
- If another directory (external, AD, Managed AD) is set up, AWS Control Tower does not change the existing configuration.
Prep Existing Accounts For Enrollment
https://docs.aws.amazon.com/controltower/latest/userguide/enroll-account.html provides pre-reqs for the Account Enrollment into Control Tower.
The document says the following:
- Before you can enroll an existing AWS account into AWS Control Tower you must give permission for AWS Control Tower to manage, or govern, the account so you need to Set Up Trusted Access First.
- Use an AWS Config conformance pack to evaluate how your accounts may be affected by some AWS Control Tower guardrails. See Extend AWS Control Tower governance using AWS Config conformance packs.
- You may need to remove the AWS Config delivery channel and configuration recorder that were created for your evaluation. Check my other blog also for the journey I had to take: https://dunlop.geek.nz/migrating-old-aws-accounts-into-control-tower-enrollment-my-journey/
- Set up an Unregistered OU for storing your AWS Accounts to enroll
Also this blog post has useful field notes: https://aws.amazon.com/blogs/architecture/field-notes-enroll-existing-aws-accounts-into-aws-control-tower/ which has a very useful python script that supports enrolling all accounts within an unregistered OU in to AWS Control Tower. Be mindful: It takes up to 30 minutes to enroll each AWS account in to AWS Control Tower. The accounts can be enrolled only one at a time. Depending on number of accounts that you are migrating, you must keep the session open long enough.
Think this covers the gaps. If I’ve missed anything please let me know.