# Core concepts **Topics** + [ # AWS Organizations ](aws-organizations.md) + [ # Benefits of using organizational units (OUs) ](benefits-of-using-organizational-units-ous.md) + [ # Multiple organizations ](multiple-organizations.md) # AWS Organizations AWS Organizations [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) helps you centrally govern your environment as you grow and scale your workloads on AWS. Whether you are a growing startup or a large enterprise, Organizations helps you to centrally provision accounts and resources; secure and audit their environment for compliance; share resources; control access to accounts, Regions, and services; as well as optimize costs and simplify billing. Additionally, Organizations supports aggregation of health events, consolidated data on use of access permissions, and centralized management of backups and tagging for multi-account environments. This section includes best practices for organizing your AWS accounts, including grouping your accounts into organizational units (OUs) so that you can more effectively secure and manage your overall AWS environment. ## What is an Organization? What is an Organization? An organization is an entity that you create to consolidate a collection of accounts so that you can administer them as a single unit. Within each organization, you can organize the accounts in a hierarchical, tree-like structure with a [root](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html#root) at the top and [organizational units (OUs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html#organizationalunit) nested under the root. Each account can be placed 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 ## Organizations management account Organizations management account The management account creates the AWS organization's resources, OUs, and policies, to manage the organization's member accounts. Access to the management account must be strictly controlled by a small set of highly-trusted individuals from the organization, following the [Principles of Least Privilege](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_permissions_least_privileges.html) based on the activities they need to perform. This account **should not** be used for business workloads and should not contain business resources. Additionally, the organization management account is where automation tooling is installed to automate consistent deployment of controls or other standardized infrastructure constructs across accounts in an organization. A trust relationship, which is used by the automation tooling, exists between child AWS accounts in the organization and the organization management account. This relationship is established by default when new AWS accounts are created in the organization, and it enables management account users and roles to assume this cross-account [AWS Identity and Access Management](https://aws.amazon.com/iam/) (IAM) [role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) in child accounts. ### Considerations for setting up the management account: Considerations for setting up the management account: Most customers start with one AWS account, where they build some Proof of Concepts (PoCs) before deploying their workloads on AWS. In this situation, we recommend creating a new AWS account to be your management account, and [inviting your existing account](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_invites.html) into your new AWS organization. This allows you to keep any PoCs or workloads that you might already have in that account intact. When you set up the management account, we recommend using an email address that belongs to a shared mailbox, to avoid losing access to this account if only one individual has access to this email address, and for example, they leave your organization or lose access to the account. ## Organizations member accounts Organizations member accounts AWS Organizations member accounts belong to the organization and reside in the overall organization's structure. All billing for member accounts is consolidated to the management account of the organization. Most of your workloads will reside in member accounts, except for some centrally managed processes that must reside in either the management account or in accounts assigned as designated administrators for specific AWS services. ## Organizational units (OUs) Organizational units An organizational unit (OU) provides a means to group accounts within a root. An OU can also contain other OUs. 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 each account can be a member of exactly one OU. OUs are not meant to mirror your own organization's reporting structure. Instead, OUs are intended to group accounts that have common overarching security policies and operational needs. The primary question to ask yourself is: How likely will the group need a set of similar policies? The following diagram shows a basic organization that consists of seven accounts that are organized into four OUs under the [root.](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html#root) The organization also has a few policies that are applied to OUs. ![\[Diagram showing an example of a basic organization\]](http://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/images/basic-organization-example.png) # Benefits of using organizational units (OUs) Benefits of using OUs The following benefits of using OUs helped shape [Recommended OUs and accounts](recommended-ous-and-accounts.md). ## Group similar accounts based on function Group similar accounts based on function When you have multiple accounts that perform either similar or related functions, you can benefit from grouping these accounts into distinct top-level OUs. Prudent use of top-level OUs can help your teams better understand the overall structure of your AWS accounts. For example, these best practices recommend [a set of top-level OUs](recommended-ous-and-accounts.md) to help you organize different sets of related accounts. At a minimum, the top-level OUs are used to distinguish between overall functions of accounts. ## Apply common policies Apply common policies OUs provide a way for you to organize your accounts so that it's easier to apply common overarching policies to accounts that have similar needs. Policies in AWS Organizations enable you to apply additional types of management to the accounts in your organization. By attaching policies to OUs rather than to individual accounts, you can simplify management of policies across groups of similar accounts. As the number of accounts in your environment grows, simplifying policy management by attaching policies to OUs becomes more important. AWS Organizations supports use of authorization and management policies. For a complete list of policy types, refer to [Managing AWS Organizations policies.](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies.html) ### Authorization policies Authorization policies + **Service control policies (SCPs):** SCPs are a type of organization policy that you can use to manage permissions in your organization. SCPs offer central control over the maximum available permissions for all accounts in your organization. SCPs are a means of implementing controls in your AWS organization. Your use of SCPs can help ensure that your accounts stay within your access control guidelines. For example, you can use SCPs to constrain the set of AWS services and actions allowed on resources. + Use SCPs to restrict your AWS Organizations' IAM principals' access to services and resources, or the conditions under which IAM principals can make requests. Refer to SCP examples and guidance on when to use SCPs. + **Resource control policies (RCPs):** RCPs are another type of authorization policy that you can use to manage permissions in your organization. RCPs offer central control over the maximum available permissions for resources in your organization. RCPs help you to ensure resources in your accounts stay within your organization's access control guidelines. + Use RCPs to restrict who can access your resources, and enforce requirements on how your resources can be accessed. For example, only trusted external accounts can access specific Amazon S3 buckets hosted in your organization. Refer to RCP examples and guidance on when to use RCPs. Although you can apply SCPs and RCPs to the root of your organization, you typically associate these policies with underlying OUs. For example, based on the nature of the workloads deployed in accounts within an OU, you might choose to restrict the set of AWS services and AWS Regions that are allowed to be used by accounts in the OU. The effective permissions are the logical intersection between what is allowed by the RCPs and SCPs, and what is allowed by the identity-based and resource-based policies. **Note** Authorization policies (SCPs and RCPs) don't affect users, roles, or resources in the management account. They affect only the member accounts in your organization. This also means that SCPs and RCPs apply to member accounts that are designated as delegated administrators for policy management. ### Management policies Management policies You can also apply the following policies to your organization: + [Tag policies](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html): Tag policies can help you monitor and ensure compliance with your cloud resource tagging standards. + [AI services opt-out policies:](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_ai-opt-out.html) You can use artificial intelligence (AI) services opt-out policies to control data collection for AWS AI services for all of your organization's accounts. + [Backup policies](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_backup.html): Backup policies can help you centrally manage and apply backup plans to the AWS resources across your organization's accounts. + [Chatbot policies](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_chatbot.html): Chatbot policies can help you to control access to your organization's accounts from chat channels. You can use Chatbot policies to determine which permissions models, chat platforms and chat workspaces can be used to access the accounts. + [Declarative policies for EC2:](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_declarative.html) Declarative policies allow you to centrally declare and enforce your desired configuration for a given AWS service at scale across an organization. Once attached, the configuration is always maintained when the service adds new features or APIs. + Use declarative policies to prevent non-compliant actions. For example, you can block internet access to Amazon VPC resources across your organization. ## Share common resources Share common resources OUs provide a means for you to organize your accounts so that it's easier for you to share centrally managed resources across similar accounts. AWS services have been introducing support for sharing their resources through [AWS Resource Access Manager](https://aws.amazon.com/ram/) (AWS RAM) and AWS Organizations. For example, with AWS RAM, you can use OUs as the basis for sharing centrally managed network resources such as [Amazon Virtual Private Cloud](https://aws.amazon.com/vpc/) (Amazon VPC) [subnets](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-sharing.html). ## Provision and manage common resources Provision and manage common resources Sometimes you need to deploy common, centrally managed resource configurations to groups of related accounts. In cases where resource sharing doesn't apply, you can use a variety of AWS services and third-party tools that work with OUs to automatically roll out and update your own custom resources. For example, you can use OUs as a basis for targeting automation to deploy and update your own sets of IAM roles and [customer managed IAM policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html) that help establish common baseline and/or workload-specific security controls to groups of related accounts. # Multiple organizations Multiple organizations Most customers are best served using a single production organization and a test organization. This allows you to ensure consistency across accounts in your environment because centrally-applied policies or service-level configurations are programmatically applied across accounts within your organization. Separating your workload accounts across organizations requires additional overhead or customization to ensure central standards are applied within each organization. There are certain exceptions, outlined in this section, where you might need to work across multiple organizations. ## Test changes to your overall AWS environment Test changes to your overall AWS environment It is recommended to develop infrastructure as code that interacts with APIs and other mechanisms fundamental to the management of your AWS Organization. In these cases, to determine whether your changes break something without having to make the changes in your production organization, we recommend that you test your changes in an organization different from the one running your production workloads. For example, you might need to either modify the automation that creates new accounts to change the configuration baseline of accounts it creates or change the configuration of a workflow management system you're using to modify SCPs. In addition, you might want to test the delegated administration capabilities of various AWS services prior to applying them in your production organization. In these circumstances, we recommend that you establish an additional AWS Organization for testing that closely resembles your production organization. You can perform testing of changes to how you manage your organization in your test organization before applying those changes to be applied to your production organization. ## Support acquisitions and divestments Support acquisitions and divestments You might acquire an entity that has already established an organization. If you decide to merge the acquired entity's AWS environment with your AWS environment, you can move member accounts from the acquired organization to your mainstream organization. In this case, you can later decommission the acquired entity's organization. If you plan to potentially divest a portion of your portfolio, you can manage the workloads and supporting AWS accounts for that portion of your portfolio in a separate organization to support simpler divesture and isolated billing. ## Support large AWS environments You can request a [quota increase](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) if your AWS Organization reaches its maximum account limit. Support can help expand your organization's capacity beyond the default number of accounts. For more details about the maximum number of accounts supported in an organization, refer to [Quotas for AWS Organizations.](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_reference_limits.html) ## Align with your billing requirements Align with your billing requirements An organization gathers billing information from all member accounts into a single consolidated AWS bill. If you have use cases where different sets of accounts require distinct bills or payments, then multiple organizations might be required. Ensure you have reviewed AWS Billing and Cost Management Conductor and Billing and Management Credit sharing options for your AWS accounts to understand the configurations that are supported within a single AWS Organization. ## Different classification levels for government applications Different classification levels for government applications Some customers in government, critical national infrastructure providers, and defense industries need to handle data with defined classification levels. These customers require high-assurance mechanisms to keep data (and, in most cases, metadata) associated with at least some of those markings, separate from each other. Assets within a single account should all handle data at the same protective marking. As noted in this section, an organization itself contains collective data from multiple accounts. Data such as account names, billing data, organizational unit names, and activity logs can be accessed centrally for those with appropriate permissions, such as a cloud administrator or audit team. This means that commingling of billing and logging data from accounts that are processing data might not meet a customer's requirements for separation by classification levels. An organization's configuration could be modified to have customized separation for protective marking with proper tags, logging customization (based on protective markings), and defined permissions for administrative users. However, this might be more easily achieved with separate organizations.