There are a number of ways to group and arrange your AWS accounts. How you do this is completely up to you, but here are a few examples to consider:
- Business unit (BU) or location: You may wish to allow each BU to work in isolation on their own products or services, on their own schedule, without impacting other parts of the business
- Cost center: Grouping according to cost may help you track spend versus allocated budget
- Environment type: It may make sense to group your development, test, and production environments together in a way which helps you manage the controls across each environment
- Workload type or data classification: Your company may want to isolate workload types from each other, or ensure that particular controls are applied to all accounts containing a particular kind of data
In the following fictitious example, we have isolated the Sitwell Enterprises Account from the rest of the organization by placing it in an OU called Sudden Valley. Perhaps they operate in a different geographical location and have different regulatory requirements around controls and access.
Organization hierarchy
Note that while it's also technically possible for us to put the master account inside an OU, we avoid doing this to make it obvious that:
- It's the master account and has control over the entire organization
- The rules we set, using SCPs for the member accounts in our organization, do not apply to the master account (because they can't)
Learn more about SCPs in the Adding a service control policy recipe in this chapter.