As was mentioned earlier, AWS Organizations is an account management service. Its role is to help large and complex organizations handle their AWS environment more efficiently. You can use AWS Organizations to manage security policies across accounts and filter out unwanted access, automate the creation of new accounts through its application programming interfaces (APIs), organize accounts into OUs, and consolidate billing across multiple accounts.
When you set up an organization with AWS Organizations, the AWS account that you use to set it up becomes the management account of that organization. As you invite other accounts to join your organization or directly create new accounts in your organization, these accounts then become member accounts.
There are two major modes of working with AWS Organizations: either with all features enabled or with consolidated billing only. Consolidated billing only provides a central consolidated bill of all the member accounts of the organization and does not provide access to advanced functionalities such as centrally managed security policies. To benefit from these advanced features, you must enable all features in your organization.
As mentioned in the previous section, AWS Organizations helps you take security and governance to the next level, provided that you enable all features. It does this by means of specific policies, but instead of managing these policies at the individual account level, it allows you to handle them at the organization level.
There are two main types of policies that you can enforce at the organization level—authorization policies and management policies.
Authorization policies consist of SCPs, which offer the capability to centrally manage the maximum permissions that can be granted to Identity and Access Management (IAM) entities (users or roles) across either your entire organization or one or more specific OUs. The concept of SCP is, in a way, similar to that of IAM permissions boundaries, which we covered in Chapter 1, Determining an Authentication and Access Control Strategy for Complex Organizations, whereby the intention is not to grant permissions directly but to limit the perimeter of the permissions that can be granted to IAM entities. The major difference between the two is that SCPs apply at the organization or OU level while permissions boundaries apply at the more granular level of IAM entities.
Note that SCPs are not enabled by default—you must enable them in your organization to be able to use them. We will dive deeper into SCPs in the dedicated section titled Setting up SCPs later in this chapter.