There are a number of ways to group and arrange your AWS accounts. How you do this is completely up to you, but the following are a few examples to consider:

• Business unit (BU) or location: You may wish to allow each BU to work in isolation on its own products or services, on its own schedule, without impacting other parts of the business.
• Cost center: Grouping according to cost may help you track spending versus the allocated budget.
• Environment type: It may make sense to group your development, test, and production environments together in a way that 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 the 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:

Note that, while it's also technically possible for us to put the master account inside an OU, we avoid doing this to make the following obvious:

• It's the master account and it has control over the entire organization.
• The rules we set using the SCPs for the member accounts in our organization do not apply to the master account (because they can't).

You can learn more about SCPs in the Adding a Service Control Policy (SCP) recipe in this chapter.