Using multiple AWS accounts to help isolate and manage your business applications and data can help you optimize across most of the AWS Well-Architected Framework(WAF) and and AWS Cloud Adoption Framework(CAF) pillars

Prerequisites

Usually at the beginning of the J2C project, AWS Cloud Adoption Framework(CAF) is the first step. The management level of the enterprise will make the J2C assessment.

• Business perspective
• People perspective
• Governance perspective
• Platform perspective
• Security perspective
• Operations perspective

AWS Cloud Readiness Assessment(CART) can be used for the assessment. CART collects many questions to help the customer to make the cloud adoption assessment.

https://cloudreadiness.amazonaws.com/#/cart

Next, we need to design our cloud environment base on the AWS Well-Architected Framework(WAF)

• Operational excellence
• Security
• Reliability
• Performance efficiency
• Cost optimization
• Sustainability

AWS Well-Architected Tools can help the customer to design your cloud environment. There are existing lots of good question in the different Well-Architected Lens.And the customer can customize own questions and record them in AWS Well-Architected Tools. Until now,the draft AWS organization should be designed.

When we design our AWS multi-accounts,in addtion to the WAF and CAF, the following items are recommended:

• Group workloads based on business purpose and ownership
• Apply distinct security controls by environment
• Constrain access to sensitive data
• Promote innovation and agility
• Limit scope of impact from adverse events
• Support multiple IT operating models
• Manage costs
• Distribute AWS Service Quotas and API request rate limits

Core Concepts

Organization

An entity that you create to consolidate your AWS accounts so that you can administer them as a single unit. You can use the AWS Organizations console to centrally view and manage all of your accounts within your organization. An organization has one management account along with zero or more member accounts. You can organize the accounts in a hierarchical, tree-like structure with a root at the top and organizational units nested under the root. Each account can be directly in the root, or placed in one of the OUs in the hierarchy. An organization has the functionality that is determined by the feature set that you enable.

Root

The parent container for all the accounts for your organization. If you apply a policy to the root, it applies to all organizational units (OUs) and accounts in the organization.

Organizational unit (OU)

A container for accounts within a root. An OU also can contain other OUs, enabling you to create a hierarchy that resembles an upside-down tree, with a root at the top and branches of OUs that reach down, ending in accounts that are the leaves of the tree. When you attach a policy to one of the nodes in the hierarchy, it flows down and affects all the branches (OUs) and leaves (accounts) beneath it. An OU can have exactly one parent, and currently each account can be a member of exactly one OU.

Account

An account in Organizations is a standard AWS account that contains your AWS resources and the identities that can access those resources.

The following picture shows the recommended AWS organization.

Naming Standard

OU ID Standard

Typically, the department ID is your OU ID

Account ID Standard

The following standard can be used to the account id

CLOUD_NAME-DEPARTMENT_NAME/FUNTIONALITY_NAME-ENV_NAME

For example:
aws-data-tst(aws cloud-data department-test environment)

Conclusion

Hopefully, the above experience can help you to design the multi-accounts. Next, I will describe how to create multi-accounts automatically.