Terminology and concepts for AWS Organizations

This topic explains some of the key concepts for AWS Organizations.

The following diagram shows an organization that consists of five 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.

Available feature sets

All features (Recommended)

All features is the default feature set that is available to AWS Organizations. You can set central policies and configuration requirements for an entire organization, create custom permissions or capabilities within the organization, manage and organize your accounts under a single bill, and delegate responsibilities to other accounts on behalf of the organization. You can also use integrations with other AWS services to define central configurations, security mechanisms, audit requirements, and resource sharing across all member accounts in your organization. For more information, see Using AWS Organizations with other AWS services.

All features mode provides all the capabilities of consolidated billing along with the administrative capabilities.

Consolidated billing

Consolidated billing is the feature set that provide shared billing functionality, but doesn't include the more advanced features of AWS Organizations. For example, you can't enable other AWS services to integrate with your organization to work across all of its accounts, or use policies to restrict what users and roles in different accounts can do.

You can enable all features for 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 management account starts the process. For more information, see Enabling all features for an organization with AWS Organizations.

Organization structure

Organization

An organization is a collection of AWS accounts that you can manage centrally and organize into 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.

Each organization consists of:

• A management account

• Zero or more member accounts

• Zero or more organizational units (OUs)

• Zero or more policies.

An organization has the functionality that is determined by the feature set that you enable.

Root

An administrative root (root) is contained in the management account and is the starting point for organizing your AWS accounts. The root is the top-most container in your organization’s hierarchy. Under this root, you can create organizational units (OUs) to logically group your accounts and organize these OUs into a hierarchy that best matches your needs.

If you apply a management policy to the root, it applies to all organizational units (OUs) and accounts, including the management account for the organization.

If you apply an authorization policy (for example, a service control policy (SCP)), to the root, it applies to all organizational units (OUs) and member accounts in the organization. It does not apply to the management account in the organization.

Note

You can have only one root. AWS Organizations automatically creates the root for you when you create an organization.

Organizational unit (OU)

An organizational unit (OU) is a group of AWS accounts within an organization. An OU can also contain other OUs enabling you to create a hierarchy. For example, you can group all accounts that belong to the same department into a departmental OU. Similarly, you can group all accounts running security services into a security OU.

OUs are useful when you need to apply the same controls to a subset of accounts in your organization. Nesting OUs enables smaller units of management. For example, you can create OUs for each workload, then create two nested OUs in each workload OU to divide production workloads from pre-production. These OUs inherit the policies from the parent OU in addition to any controls assigned directly to the team-level OU. Including the root and AWS accounts created in the lowest OUs, your hierarchy can be five levels deep.

AWS account

An AWS account is a container for your AWS resources. You create and manage your AWS resources in an AWS account, and the AWS account provides administrative capabilities for access and billing.

Using multiple AWS accounts is a best practice for scaling your environment, as it provides a billing boundary for costs, isolates resources for security, gives flexibility or individuals and teams, in addition to being adaptable for new processes.

Note

An AWS account is different from a user. A user is an identity that you create using AWS Identity and Access Management (IAM) and takes the form of either an IAM user with long-term credentials or an IAM role with short-term credentials. A single AWS account can, and typically does, contain many users and roles.

There are two types of accounts in an organization: a single account that is designated as the management account and one or more member accounts.

Management account

A management account is the AWS account you use to create your organization. From the management account, you can do the following:

• Create other accounts in your organization

• Invite and manage invitations for other accounts to join your organization

• Designate delegated administrator accounts

• Remove accounts from your organization

• Attach policies to entities such as roots, organizational units (OUs), or accounts within your organization

• Enable integration with supported AWS services to provide service functionality across all of the accounts in the organization.

The management account is the ultimate owner of the organization, having final control over security, infrastructure, and finance policies. This account has the role of a payer account and is responsible for paying all charges accrued by the accounts in its organization.

Note

You cannot change which account in your organization is the management account.

Member account

A member account is an AWS account, other than the management account, that is part of an organization. If you are an administrator of an organization, you can create member accounts in the organization and invite existing accounts to join the organization. You also can apply policies to member accounts.

Note

A member account can belong to only one organization at a time. You can designate member accounts to be delegated administrator accounts.

Delegated administrator

We recommend that you use the management account and its users and roles only for tasks that must be performed by that account. We recommend that you store your AWS resources in other member accounts in the organization and keep them out of the management account. This is because security features like Organizations service control policies (SCPs) do not restrict any users or roles in the management account. Separating your resources from your management account can also help you understand the charges on your invoices. From the organization's management account, you can designate one or more member accounts as a delegated administrator account to help you implement this recommendation. There are two types of delegated administrators:

• Delegated administrator for Organizations: From these accounts, you can manage organization policies and attach policies to entities (roots, OUs, or accounts) within the organization. The management account can control delegation permissions at granular levels. For more information, see Delegated administrator for AWS Organizations.

• Delegated administrator for an AWS service: From these accounts, you can manage AWS services that integrate with Organizations. The management account can register different member accounts as delegated administrators for different services as needed. These accounts have administrative permissions for a specific service, as well as permissions for Organizations read-only actions. For more information, see Delegated administrator for AWS services that work with Organizations

Invitations and handshakes

Invitation

An invitation is the process of asking another account to join your organization. An invitation can be issued only by the organization's management account. The invitation is extended to either the account ID or the 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. You might not see handshakes when you work in the AWS Organizations console. But if you use the AWS CLI or AWS Organizations API, you must work directly with handshakes.

Handshake

A handshake is 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. The messages are passed in a way that helps ensure that both parties 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 AWS 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.

Organization policies

A policy is a "document" with one or more statements that define the controls that you want to apply to a group of AWS accounts. AWS Organizations supports management policies and authorization policies.

Management policies

Management policies help you centrally configure and manage AWS services and their features across an organization.

Backup policy

A backup policy is type of policy that helps you standardize and implement a backup strategy for the resources across all of the accounts in your organization. In a backup policy, you can configure and deploy backup plans for your resources.

Tag policy

A tag policy is type of policy that helps you standardize tags across resources across all of the accounts in your organization. In a tag policy, you can specify tagging rules for specific resources.

AI services opt-out policy

An AI services opt-out policy is a type of policy that helps you standardize your opt-out settings for AWS AI services across all of the accounts in your organization. Certain AWS AI services can store and use customer content processed by those services for the development and continuous improvement of Amazon AI services and technologies. As an AWS customer, you can use AI service opt-out policies to choose to opt out of having your content stored or used for service improvements.

Authorization policies

Authorization policies help you to centrally manage the security of AWS accounts across an organization.

Service control policy

A service control policy is 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 permissions policies except that they don't grant any permissions. Instead, SCPs specify the maximum permissions for an organization, organizational units (OUs), or account. When you attach an SCP to your organization root or an OU, the SCP limits permissions for entities in member account.

Allow lists and deny lists

Allow lists and deny lists are complementary strategies that you can use to apply SCPs to filter the permissions that are available to accounts.

• Allow list strategy – 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 helps ensure that, as you build your organization, nothing is blocked until you want it to be. In other words, by default all permissions are allowed. 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, all accounts in the organization are affected by the restrictions. You can't add permissions back at a lower level in the hierarchy because an SCP never grants permissions; it only filters them.

• Deny list strategy – You explicitly specify the access that isn't 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 AWS Organizations–imposed restrictions. Unlike the allow list technique described above, when using deny lists, you leave the default FullAWSAccess policy in place (that allow "all"). But then you 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.