Menu
AWS Organizations
User Guide

AWS Organizations Terminology and Concepts

To help you get started with AWS Organizations, this topic explains some of the key concepts.

The following diagram shows a basic organization that consists of seven accounts that are organized into four organizational units (OUs) under the root. The organization also has several policies that are attached to some of the OUs or directly to accounts. For a description of each of these items, refer to the definitions in this topic.


      Diagram of basic organization
Organization

An entity that you create to consolidate your AWS accounts. You can use the AWS Organizations console to centrally view and manage all of your accounts within your organization. An organization has one master 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.

Note

Currently, you can have only one root. AWS Organizations automatically creates it for you when you create an organization.

Organization 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

A standard AWS account that contains your AWS resources. You can attach a policy to an account to apply controls to only that one account.

An organization has one account that is designated as the master account. This is the account that creates the organization. The rest of the accounts that belong to an organization are called member accounts. From the organization's master account, you can create accounts in the organization, invite other existing accounts to the organization, remove accounts from the organization, manage invitations, and apply policies to entities (roots, OUs, or accounts) within the organization. An account can be a member of only one organization at a time.

The master account has the responsibilities of a payer account and is responsible for paying all charges that are accrued by the member accounts. If you previously had a Consolidated Billing family of accounts, your accounts have been migrated to a new organization in AWS Organizations, and the payer account in your Consolidated Billing family has become the master account in your organization. All linked accounts in the Consolidated Billing family have become member accounts in the organization and continue to be linked to the master account. Your bills continue to reflect the relationship between the payer account and the linked accounts. For more information about accounts that are migrated from Consolidated Billing to AWS Organizations, see Consolidated Billing and AWS Organizations.

Invitation

The process of asking another account to join your organization. An invitation can be issued only by the organization's master account and is extended to either the account ID or email address that is associated with the invited account. After the invited account accepts an invitation, it becomes a member account in the organization. Invitations also can be sent to all current member accounts when the organization needs all members to approve the change from supporting only consolidated billing features to supporting all features in the organization. Invitations work by accounts exchanging handshakes. Although you might not see handshakes when you work in the AWS Organizations console, if you use the AWS CLI or AWS Organizations API, you must work directly with handshakes.

Handshake

A multi-step process of exchanging information between two parties. One of its primary uses in AWS Organizations is to serve as the underlying implementation for invitations. Handshake messages are passed between and responded to by the handshake initiator and the recipient in such a way that it ensures that both parties always know what the current status is. Handshakes also are used when changing the organization from supporting only consolidated billing features to supporting all features that Organizations offers. You generally need to directly interact with handshakes only if you work with the AWS Organizations API or command line tools such as the AWS CLI.

Available feature sets
  • Consolidated billing – The default feature set for an organization that is migrated from a Consolidated Billing family of accounts. It provides the same shared billing functionality that Consolidated Billing had, but does not include the more advanced features of AWS Organizations, such as the use of policies to restrict what users and roles in different accounts can do. To use the advanced AWS Organizations features, you must enable all features in your organization.

  • All features – The complete feature set that is available to Organizations. It includes all the functionality of consolidated billing, plus it provides advanced features that give you more control over accounts in your organization. For example, when all features are enabled the master account of the organization has full control over what member accounts can do. The master account can apply SCPs to restrict the services and actions that users (including the root user) and roles in an account can access, and can prevent member accounts from leaving the organization. You can create an organization with all features already enabled, or you can enable all features in an organization that originally supported only the consolidated billing features. To enable all features, all invited member accounts must approve the change by accepting the invitation that is sent when the master account starts the process.

Service control policy (SCP)

A policy that specifies the services and actions that users and roles can use in the accounts that the SCP affects. SCPs are similar to IAM permission policies except that they don't grant any permissions. Instead, SCPs are filters that allow only the specified services and actions to be used in affected accounts. Even if a user is granted full administrator permissions with an IAM permission policy, any access that is not explicitly allowed or that is explicitly denied by the SCPs affecting that account is blocked. For example, if you assign an SCP that allows only database service access to your "database" account, then any user, group, or role in that account is denied access to any other service's operations. SCPs are available only when you enable all features in your organization. You can attach an SCP to the following:

  • A root, which affects all accounts in the organization

  • An OU, which affects all accounts in that OU and all accounts in any OUs in that OU subtree

  • An individual account

Important

The master account of the organization is not affected by any SCPs that are attached either to it or to any root or OU the master account might be in.

Whitelisting vs. blacklisting

Whitelisting and blacklisting are complementary techniques that you can use when you apply SCPs to filter the permissions that are available to accounts.

  • Whitelisting: You explicitly specify the access that is allowed. All other access is implicitly blocked. By default, AWS Organizations attaches an AWS managed policy called FullAWSAccess to all roots, OUs, and accounts. This ensures that, as you build your organization, nothing is blocked until you want it to be. In other words, by default all permissions are whitelisted. When you are ready to restrict permissions, you replace the FullAWSAccess policy with one that allows only the more limited, desired set of permissions. Users and roles in the affected accounts can then exercise only that level of access, even if their IAM policies allow all actions. If you replace the default policy on the root, then all accounts in the organization are affected by the restrictions. You can't add them back at a lower level in the hierarchy because an SCP never grants permissions; it only filters them.

  • Blacklisting: You explicitly specify the access that is not allowed. All other access is allowed. In this scenario, all permissions are allowed unless explicitly blocked. This is the default behavior of AWS Organizations. By default, AWS Organizations attaches an AWS managed policy called FullAWSAccess to all roots, OUs, and accounts. This allows any account to access any service or operation with no Organizations-imposed restrictions. Unlike the whitelisting technique described above, when using blacklists you typically leave the default FullAWSAccess policy in place but attach additional policies that explicitly deny access to the unwanted services and actions. Just as with IAM permission policies, an explicit deny of a service action overrides any allow of that action.