After a three month preview since re:Invent 2016, Amazon Web Services has recently moved AWS Organizations to general availability. The new service allows users to centrally manage multiple AWS accounts within a hierarchy of organizational units and attach service control policies with fine-grained access permissions. AWS Organizations also supersede the formerly separate consolidated billing feature.
As outlined by Amazon Web Service's Chief Evangelist Jeff Barr, many AWS users are using multiple accounts for reasons such as incremental cloud adoption across organizational teams, or "to meet strict guidelines for compliance or to create a very strong isolation barrier", for example between development, testing, and production environments.
AWS also supports collaboration between accounts owned by the same or different organizations with cross-account features such as VPC peering, sharing of EC2 images, EBS and RDS snapshots, and cross-account console access via IAM roles. However, consistent management of these cross-account interdependencies can quickly become an operational challenge.
The dedicated AWS Organizations service now aims to reduce this complexity by offering "to centrally manage multiple AWS accounts, with the ability to create a hierarchy of Organizational Units (OUs), assign each account to an OU, define policies, and then apply them to the entire hierarchy, to select OUs, or to specific accounts".
/filters:no_upscale()/news/2017/03/aws-organizations/en/resources/AWS-Organizations-onboarding-screen.png)
The key AWS Organizations concepts are:
- Organization – an organization has one master and zero or more member accounts that can be organized in a hierarchical, tree-like structure
- Account – a regular AWS account that contains AWS resources
- Root – the parent container for all accounts within an organization
- Organizational unit (OU) – a container for accounts, which can also contain other OUs to create a hierarchy so that policies attached to an OU affect all accounts within that hierarchy
- Service control policy (SCP) – a policy in JSON format similar to Identity and Access Management (IAM) policies, which specifies the actions available to users and roles in accounts affected by the SCP
After creating an organization within a chosen master account, member accounts can either be invited to join an organization, or created within an organization, and also programmatically via the CLI or the API, thereby addressing a popular feature request. However, while accounts invited to an organization can also leave it again, accounts created within can neither leave nor be deleted yet, which is noteworthy due to the default limit of twenty organization accounts that can only be raised by requesting a service limit increase.
AWS customers who had been using the former consolidated billing have been migrated to an AWS organization and will retain the same features, including cost saving benefits for reserved EC2 and RDS instance usage and volume discounts. In this scenario, the new policy-based access control requires an additional opt-in by the master account, followed by a confirmation from each member account. Using only access control without consolidated billing is not supported.
Each account within an organization can be assigned to an organizational unit (OU) arranged in a hierarchy up to five levels deep. The hierarchy starts at the root container, which is separate from the organization to enable future support of multiple hierarchies, a key feature of the backing Amazon Cloud Directory service that has recently been launched as well.
Attaching service control policies (SCP) to nodes in the organizational hierarchy determines the actions that can be delegated to Identity and Access Management (IAM) users and IAM roles in affected accounts. AWS enforces the most restrictive combination of permissions from both the organization's SCPs and the account's IAM policies so that entities can only use actions where both the organization's and the account's administrators have granted access. SCPs within the hierarchy are evaluated as the union of all SCPs on the same element and the intersection of SCPs inherited across multiple elements in the tree.
The default strategy configured in AWS Organizations uses SCPs as blacklists: An AWS managed FullAWSAccess policy is attached to the root and each OU at creation time and explicitly allows all actions until an SCP is attached that explicitly denies specific actions in affected accounts. SCPs can also be used as whitelists by replacing the default FullAWSAccess policy with an SCP that explicitly allows only the desired actions.
The AWS Organizations documentation features a user guide, including a getting started section, the AWS CLI reference, and the API reference. A separate FAQ is also available. The service is offered at no additional charge, though users should be aware that the master account's owner "is responsible for paying for all usage, data, and resources used by the accounts in the organization". Support is provided via the AWS Organizations forum.