AWS Multi-Account Management Strategy
AWS Organisations, Organisational Units
I read this article and thought it was perfect and reflects well on what my customers are doing:
The 4 Organisational Units (OUs):
Workloads set: this contains the “meat” of the infrastructure used for the day-to-day running of our products. Each of the workload accounts represents a different environment, like Production, Staging and Development.
Sandbox set: our employees occasionally need to experiment with AWS services so they get a sandbox account to do so, without messing up our operational workloads. Budget restrictions are placed on these accounts.
Shared: as the name implies, this OU houses accounts with infrastructure that is shared between workloads/services on other accounts.
Security: where the audit, logging and other security-related accounts are. If you are managing the Security Hub and Guard Duty centrally, then that account should be in this OU.
Of cause, it depends on your use case, but this is a good reference for how you can set up your organisation’s access!
To further expand on what the above means, let me illustrate through my account set-up:
Overall, it forms an inverted tree, with 1 (Organisation) Root at the top, and many accounts across OUs at the bottom.
The management account, which acts as the master payer account, is the one attached to Root. The purpose of this account is largely for the management of the AWS Organisation and payment purposes.
You may also have nested OUs, and apply policies at Root and OU levels.
For further explanations, the AWS documentation site is great. Let me know if you have any questions!