I've spent the past few weeks refreshing myself on the latest and greatest in the AWS IAM space and applying what I can to my own personal AWS account that I use for tinkering.
A recommendation is to have one master organisation (org) and then create a separate org to hold all the audit and log data (some guidance I came across also says to have one org for audit and another for logs) and then create other orgs for your production, testing, etc environments. The setup for such was going to take quite some time and probably a bit too much for a simple dev account. However, these types of setups are the sort of environment that I spend my working life in and I have had very little insight into what is happening behind the scenes. Now, I could've followed the rather tedious instructions (and probably make a lot of mistakes along the way) to do this manually or I can use AWS Control Tower to do the heavy lifting and then look at the final outcome and tinker with it, so that is what I did.
Once the process was complete (had to create 3 additional email accounts) I was left with my original org as Root and two additional child orgs.
Security- with two AWS accounts, that I'll refer to asauditandlog-archive.Sandbox- with a single AWS account, that I'll callsandbox.
I did notice that after the AWS Control Tower process was complete I wasn't really sure what to do next or even if there was something I should be doing to make my life a little easier.
Securing
At no point did I have to create any passwords for the three additional accounts and so adding complex passwords (thank heavens for password managers) and securing with 2FA was the next chore. Feeling a bit better, I wanted to see what was going on in the Security org and the resources they were holding. Swapping between accounts quickly became tedious (password + code) and I knew I needed to set up roles in each of the new accounts that would allow my IAM account in the root org to jump between orgs and see the resources within.
Account Aliases and Roles
AWS loves their 12 digit numbers but they are hard to remember and so I make use of account aliases as much as I can. Unfortunately all the good (and obvious/simple) aliases have gone and so you'll probably need to be inventive, but if you're lucky you'll find something you can tolerate.
In each of the three new accounts, I created a role called admin that granted the AdministratorAccess policy to the root account, using the Another AWS account flow; I also took the opportunity to give each account a simple alias. AWS Control tower also creates similar roles but they are extremely wordy (ie long and hard to remember) and also differ in name from account to account.
With these new roles in place, I can now log-in to the original root account as my IAM user (not the root user) and then use the Switch Roles feature to hop between the Root, Security and SandBox orgs quickly. For the account, I could use the account alias rather than the number and so in the UI so rather than admin @ 123456789012, you see admin @ <alias> which is a lot easier to remember.
If I had other users in my account then I would look into creating roles with fewer permissions (ie read-only) in the Security org and allowing others the use of that role instead.
As always this is a note to my future self but your feedback is appreciated.