Overview of AWS Organizations
AWS Organizations provides policy-based management for multiple AWS accounts. With AWS Organizations, you can create account groups and apply policies to these groups. Organizations enables centralized policy management across multiple accounts without the need for custom scripts or manual operational processes.
Using AWS Organizations, you can create Service Control Policies (SCPs) to centrally control how multiple AWS accounts use AWS services. Organizations supports creating new accounts via API, SDK, and Console interfaces. Additionally, Organizations simplifies billing for multiple accounts by allowing you to consolidate billing, enabling a single payment method for all accounts within your organization. All AWS customers can use AWS Organizations at no additional cost. Note that an AWS account can belong to only one Organization.
Key Concepts in AWS Organizations
Before diving into AWS Organizations, it is essential to understand the key terms and concepts:
Organization
- An organization is a collection of AWS accounts that you can organize into a hierarchy and manage centrally.
AWS Account
- An AWS account is a container for your AWS resources, such as Amazon S3 buckets and Amazon EC2 instances.
- AWS resources are managed using AWS Identity and Access Management (IAM) rules (users, roles).
- The smallest management unit in AWS Organizations.
Master Account
- The account that pays for all accounts in the organization.
- Acts as the hub node for managing your organization.
Organizational Unit (OU)
- An OU is a group of AWS accounts within an organization.
- Adding AWS accounts to logical groups makes account management more convenient.
- AWS accounts and OUs can be members of another OU.
- An AWS account can be a member of multiple OUs.
Administrative Root
- The administrative root is the starting point for organizing AWS accounts and serves as the top-level container in the entire organizational hierarchy.
Organization Control Policy (OCP)
- A configuration containing one or more statements that define the control policies you want to apply to a set of AWS accounts.
- Different application scenarios use different organization control policies.
The following diagram helps visualize the relationships between these concepts:
Below is a detailed introduction to the concepts mentioned above:
Ways to Join an Organization
1. Create a new account from within the Organization
1.1 New AWS accounts can only be created by the master account.
1.2 During the account creation process, you can configure the following information:
Email Address (Required)
Account Name (Required)
IAM Role Name (Optional – default name is OrganizationAccountAccessRole)
- Enables trust permissions for the master account to access the current account via AssumeRole.
- Permissions are set to full control.
- IAM Billing Access (Optional). Note: IAM users still require relevant IAM permissions to access billing.
1.3 New AWS Accounts
Automatically become part of your organization.
Can be removed from the organization, but policies can prevent them from executing “Leave Organization” actions.
2. Invite existing accounts to join the Organization
2.1 Invitations can only be initiated by the master account.
2.2 The invited AWS account can choose to accept or reject the invitation.
Default behavior is rejection.
Can be controlled via IAM permissions.
2.3 When an invitation is accepted:
The AWS account becomes a member of the organization.
Applicable OCP rules are automatically applied to this account.
2.4 Invited AWS accounts can be removed from the organization, but policies can prevent them from executing “Leave Organization” actions.
Logical Groups for AWS Accounts (OUs)
- Adding AWS accounts to logical groups makes account management more convenient.
- AWS accounts and OUs can be members of another OU.
- An AWS account can be a member of multiple OUs.
As shown in the figure below:
OCP (Organization Control Policy)
1. Describes the control policies to be applied.
2. Different usage scenarios have different application control policies (OCP).
3. Application control policies (OCP) can be attached to:
- Organization
- Organizational Unit (OU)
- AWS Account
4. OCPs have inheritance properties (AWS Account, OU, Organization):
- Policies are inherited; meaning an OU inherits the organization’s policy, and an AWS Account inherits the OU’s policy.
- An Account’s policy moves with it. If an Account moves from one OU to another, its associated policy moves with it. It will no longer receive the previous OU’s policy but will receive the new OU’s policy.
OCP Support in V1: Service Control Policies (SCPs)
1. Allows access control for AWS service APIs:
- Define a list of allowed APIs – Whitelist.
- Define a list of denied APIs – Blacklist.
2. Service Control Policies cannot be overridden by local administrators.
3. For IAM users and roles, the effective permissions are the intersection of the Service Control Policy and the relevant IAM permissions.
4. Necessary but not sufficient: Local users must possess both SCP permissions and IAM permissions for a specific action.
5. The IAM Policy Simulator is aware of SCPs.
6. SCP permissions take precedence over local administrator permissions.
The following image shows examples of writing SCPs using whitelists and blacklists:
SCPs use IAM policy syntax. Like IAM Policies, there are two differences:
- The Resource must be “*”.
- No Condition element.
Be sure to note that to allow end-user actions, both SCP and IAM Permission must be present. As shown in the figure below, if SCP allows S3 and EC2, but IAM Permission allows EC2 and SQS, the final user will only have EC2 permissions.
Simplified Billing Management
- A single payer account pays for all accounts.
- Resources from all AWS accounts in the organization are consolidated into a single bill and benefit from tiered pricing.
- All existing consolidated billing families will be migrated to the organization’s billing model.
Different Management Levels for Organizations
You can choose different management levels when creating a new organization:
1. Billing Mode
- Backward compatible with the current Consolidated Billing (CB) mode.
- Organizations created from a consolidated billing family are automatically set to Billing Mode.
2. Full Control Mode
- Includes all features of Billing Mode.
- Enables all types of OCP management features.
- Converting from Billing Mode to Full Control Mode requires consent from all AWS accounts in the organization.
Hands-on: Managing Your Organization with AWS Organizations
Below is a demonstration of how to quickly, conveniently, and accurately manage multiple accounts using the AWS Organizations service.
1. Access the AWS Organizations Service
You can access the AWS Organizations service by searching for it in the Services menu or by clicking “My Organization” under the Account menu. This service does not appear in the standard Services dropdown menu.
Search in Services bar:
Dropdown under Account menu:
2. Create a New Organization
On the AWS Organizations service interface, select “Create Organization.” Choose the type of organization you wish to create. In this demo, I selected Full Control Mode. If you only wish to perform Consolidated Billing, select “Enable Only Consolidated Billing” on the right. Regardless of the mode chosen, billing will be consolidated. The difference lies in whether the Master Account can control joined accounts.
Note: The Consolidated Billing feature has now been migrated to AWS Organizations. If you click My Account -> Consolidated Billing under the master account, you will see this prompt, and clicking “View Linked Accounts” will directly redirect you to the AWS Organizations interface.
After creation, the organizational structure management interface appears. The account marked with an asterisk (*) is the Master Account.
3. Add New Accounts to the Organization
After creating an Organization, there are two ways to add accounts:
- Add an account directly.
- Invite other accounts to join.
3.1 Directly Add an Account
Enter the full name and email address of the account you wish to add, and assign an IAM Role. This IAM Role grants the new Account full administrative control.
It takes a few seconds for the Account to be created. Compared to manually creating an account on the AWS website, this is significantly faster. However, no password is set during creation; the user must log in to the console and click “Forgot Password” to reset it.
Log in to the newly created account via the Global Root Account console. Since the password is unknown, click “Forgot Password” to reset it. A reset link will be sent to the registered email address. Click the link to reset the password and log in again.
After logging in, you can see that the new account is operational, and the Consolidated Billing feature is enabled by default. It also indicates that the account is part of an Organization.
3.2 Invite Other Accounts to Join
Click “Invite Account” to invite other accounts. Enter the account number or email address and click Invite.
On the right side of the interface, click “Invitations” to view information about invited accounts.
At this point, the registered email of the invited account will receive an invitation email from the Master Account. To accept the invitation and join the Organization, you can either click the link in the email or go directly to the Organization interface under your own account to accept it.
In the Invitation interface, you can see the Organization ID, the inviting Account, the type of control requested, and any notes included with the request.
Finally, returning to the master account, you can see information including the Master Account, actively created Accounts, and Accounts that joined via invitation.
Removing Accounts from an Organization
There are two ways to remove an account from an Organization:
1. The Master Account proactively removes the account. Select one or more accounts and click Delete.
2. An account already in the Organization leaves the Organization. Under that Account, select “My Organization” to view the Organization information and choose to leave.
Managing Multiple Accounts Using OUs
Initially, there are no OUs in the Organization; users must add them manually. Each level of OU can add its own child OUs, forming a tree structure.
You can create a multi-level OU structure, including a root OU, two first-level OUs, and two second-level OUs.
All accounts are located in the root OU by default. You can select one or more accounts and move them to any OU. Currently, you can only move accounts to OUs; you cannot proactively add accounts from an OU.
Different policies can be enabled for different OUs to control the accounts beneath them. However, to enable this feature, you must first activate it under the Root OU.
Managing Account Behavior Using Policies (Service Control Policies)
When using Policies to manage accounts, always remember two principles:
1. Policies are inherited and move with the Account:
- Policies are inherited; meaning an OU inherits the organization’s policy, and an AWS Account inherits the OU’s policy.
- An Account’s policy moves with it. If an Account moves from one OU to another, its associated policy moves with it. It will no longer receive the previous OU’s policy but will receive the new OU’s policy.
2. The final behavior of Users under an Account is determined jointly by SCP and IAM Permissions.
Be sure to note that to allow end-user actions, both SCP and IAM Permission must be present. As shown in the figure below, if SCP allows S3 and EC2, but IAM Permission allows EC2 and SQS, the final user will only have EC2 permissions.
Service Control Policies can be configured under the “Policies” section. By default, there is a “FullAWSAccess” policy that grants all permissions, which is attached to the Root OU. This means that by default, any account joining the Organization has permission to operate all AWS services. If you wish to modify the SCP, you can click the Policy Editor on the right.
The format of SCPs is consistent with IAM Policy formats, but with two differences. After modifying or creating a Policy, it can be attached to any OU or Account:
- The Resource must be “*”.
- No Condition element.
Clicking “Create Policy” in the top left corner of the Policies interface allows you to create an SCP from scratch. You can choose to use the Policy Generator to help generate a new SCP or copy an existing one. During creation, you can choose between Whitelist or Blacklist modes.
Here, I chose the Whitelist mode to create an SCP named “SCP_Allow_access_VPC_subnet,” which only allows the Account to create and view VPCs and Subnets, denying all other actions.
Assign the created SCP to the OU, so this SCP will be passed down to accounts added below it.
In the SCP configuration interface, detach the original “FullAWSAccess” policy and add the newly created “SCP_Allow_access_VPC_subnet” policy. At this point, a problem arises: because this Account inherits the SCP of its OU, and the OU inherits the SCP of its parent OU, the Phoenix Yao Account currently has two SCPs: “FullAWSAccess” (all permissions) and “SCP_Allow_access_VPC_subnet” (restricted permissions).
What happens in this case? Similar to IAM Policies, SCPs enforce the least privilege principle. So, when you open the VPC interface using the Phoenix Yao account, you will find that you cannot view any information other than VPCs and Subnets. Also, note that policy enforcement may take some time; results are not immediate.
Let’s look at the combined effect of IAM policies and SCPs. Use the Phoenix Yao root account to create a User and assign an IAM Policy that allows all actions except viewing Subnets.
Attach this Policy to the IAM Permissions of the newly created IAM User.
Restore the SCP to “FullAWSAccess” to test if the IAM Permission takes effect independently. It is found to be effective.
Finally, use SCP and IAM Permission together. The result should be the least privilege, i.e., only able to view VPCs.
Best Practices for Using AWS Organizations
Below are some best practices for using the AWS Organizations service:
1. Use the CloudTrail service to monitor activities of the Master Account.
2. Do not manage resources through the Master Account.
3. Follow the “principle of least privilege” when managing your organization.
4. Use OUs to distribute and manage account permissions.
5. Assign only necessary permissions to the Organizations root account.
6. Test permissions using a single AWS Account first.
7. Avoid using both “whitelist” and “blacklist” strategies simultaneously within one organization.
8. Ensure there is a valid reason for creating each new AWS Account.
Granting Least Privilege to Organizations
- Set corresponding IAM permissions for all AWS Organization actions.
- You can also manage elements related to AWS Organizations (organizations, organizational units, AWS accounts) as resources for IAM rules.
- You can delegate permissions to manage your organization to an IAM user in another AWS account via IAM Roles.
- All organization management actions can be recorded via the AWS CloudTrail service.