As businesses expand their footprint on AWS and utilize more services to build and deploy their applications, it becomes apparent that multiple AWS accounts are required to manage the environment and infrastructure.
A multi-account strategy is beneficial for a number of reasons as your organization scales. Some examples of why people use multi-account strategies include:
- Cost optimization and billing
- Security and governance
- Controlling workloads
- Resource grouping
- Defining business units
As you begin to expand with multiple accounts, it becomes increasingly difficult to manage them as separate entities. The more accounts you have, the more distributed your environment becomes and the associated risks multiply.
AWS Organizations provides a means of centrally managing and categorizing multiple AWS accounts that you own. This helps maintain your AWS environment from a security, compliance, and account management perspective.
To understand how AWS organizations works to simplify things, we first need to be aware of the hierarchy of service’s components.
AWS Organizations Components
AWS Organizations uses the following components:
- Organizational Units
- Service Control Policies
An Organization is an element that serves to form a hierarchical structure of multiple AWS accounts. You could think of it as a family tree which provides a graphical view of your entire AWS account structure. At the very top of this Organization, there will be a Root container.
The Root object is simply a container that resides at the top of your Organization. All of your AWS accounts and Organizational units will sit underneath this Root. Within any Organization, there will only be one single Root object.
Organizational Units (OUs) provide a means of categorizing your AWS Accounts. Again, like the Root, these are simply containers that allow you to group together specific AWS accounts. An OU can connect directly below the Root or even below another OU (which can be nested up to 5 times). This allows you to create a hierarchical structure as I mentioned previously.
These are simply your AWS accounts that you use and create to be able to configure and provision AWS resources. Each AWS account has a 12 digit account number.
Service Control Policies
Service control policies (SCPs) allow you to control what services and features are accessible from within an AWS account. These SCPs can either be associated with the Root, Organizational Units, or individual accounts. When an SCP is applied to any of these objects, its associated controls are fed down to all child objects. Think of it as a permission boundary that sets the maximum permission level for the objects that it is applied to.
SCPs are different from both identity-based and resource-based policies as they grant permissions to users, groups, and roles. However, SCPs do not actually grant permissions themselves. Restrictions made within an SCP set a boundary of permissions within an AWS account. For example, let’s say a user within an AWS account had full access to S3, RDS, and EC2 via an identity-based policy. If the SCP associated with that AWS account denied access to the S3 service, then that user would only be able to access RDS and EC2, despite having full access to S3. The SCP would serve to prevent that service from being used within the AWS account.
How to set up AWS Organizations
Setting up an Organization is a very simple process that starts from a master AWS account. This is just a standard AWS account that you have chosen to create the AWS Organization. It’s best practice to use this AWS account solely as a master account, and not to use it to provision resources such as EC2 instances. This allows you to restrict access to the master account at a greater level. Due to its ability to manage and control other AWS accounts, the fewer users who need to access it, the better.
Once you have selected your AWS account to be used as a master account, you can create an AWS Organization. From here, you have two choices for an organization type:
- Enable all features
- Enable only consolidated billing
If you want to set up the types of Service Control Policies like those mentioned above, you will need to select ‘Enable all features’. The second option allows you to control payment and manage costs centrally from that master account across all associated AWS accounts within the Organization.
When the Organization is created, the master account can create Organizational Units for AWS account management as required. The master account can also invite other ‘member’ AWS accounts to join the Organization. The account owner of these invited AWS accounts will then receive an email requesting that their AWS account join the Organization.
Once the accounts have joined the Organization, the master account can then move these accounts into the corresponding OUs that have been created and associate relevant SCPs with them.
Key Benefits and features of AWS Organizations
Now we have an understanding of what AWS Organizations is exactly, what benefits can this bring to your AWS environment?
The primary benefit that this service brings is its ability to centrally manage multiple Accounts from a single AWS account, known as the master account. You can start today by joining your existing accounts to an Organization and on a move-forward basis, by creating new accounts directly from the service.
Greater control of your AWS environment
Through the use of Service Control Policies attached to the Root, Organizational Units or individual accounts, administrators of the master account gain powerful control over which services and features—even down to specific API calls—that an IAM user within those accounts can use, regardless of the user’s identity-based or resource-based permissions.
The master account of your AWS Organization can be used to consolidate the billing and costs from all member AWS accounts. This allows for greater overall cost management across your individual AWS accounts.
Categorization and grouping of accounts
By leveraging Organizational Units, you can segregate and group specific AWS accounts together, applying different SCPs to associated to each OU. For example, you may have a number of AWS accounts who must not have the ability to access any Analytical services. In this case, you could place these accounts into a single OU and assign an SCP that denies this functionality.
If you enjoyed this blog post you can learn more about Security and Governance in this dedicated Learning Path.