AWS offers a means to organisation the usage of the platform, and to manage multiple accounts within a single organisation. None of this is that straightforward given the inherent complexity of most large organisations. AWS Organizations provides a way to centralize control, an ability to organize accounts and apply policies to specific accounts, and a means to consolidate billing and limit what users can do in those accounts.
Organization. This is an entity that groups accounts together. Users can manage accounts within an organization as a single component.
Organizational units. A node within the root that holds AWS accounts and organizational units, which creates a nested hierarchy. An OU can have policies assigned to it that apply to any accounts nested inside of it.
Account. A standard AWS account that encapsulates AWS resources and the identities that access them. In AWS Organizations, there are two types of accounts: management and member.
Root OU. A parent node for accounts in an organization. Any policy applied to the root will also apply to all organizational units and accounts in the organization.
Service control policy. A type of policy that helps manage access control and permissions.
Tag policy. A type of policy that sets tagging rules for resources. It also standardizes tags across resources in accounts.
When you enable AWS Organizations from an AWS account, that account becomes the management account for that organization. An organization is essentially the entity in which you consolidate AWS accounts.
Any accounts you add to the organization after creating the management account become member accounts. The management account can organize different accounts into separate organizational units, or OUs. An OU is a collection of accounts that you can manage as one unit. It creates a nested hierarchy of accounts for admins to apply management policies and controls.
For example, say that your group within a big firm manages an AWS account for an application that only uses EC2 and S3. You run separate member accounts for each environment such as development, pre-production or testing; and production. You need to ensure that other services are not available in that member account. If the member accounts for each environment are in the same OU, you can set a service control policy to block all other AWS services and apply it to that OU.
Now let’s say that you need to add a tagging policy to the member accounts that contain that application. Keep all member accounts in an OU because you can apply policies at the OU-level. Those policies will apply to any accounts in that OU — everything in the OU inherits the policy. If you were to manage policies for each account individually, you would need to add that policy to each member account separately.
The management account can create OUs and manage member accounts. It can also manage policies, such as service control policies (SCPs).
However, SCPs cannot manage the management account, nor can they restrict any users or roles within the management account. Those users and roles will run as if no policies have been applied. This can create problems for the other accounts in your organization. For example, if any credentials in the management account are compromised, it can cause issues with other accounts.
If you have any resources in the management account, move them to member accounts. Then, add those accounts to the AWS organization owned by the management account as member accounts. AWS recommends that the only resources you have in your management account are CloudWatch and CloudTrail. This enables admins to monitor users logging into the account to manage the organization.
Once member accounts are in an OU, they don’t have to stay there. Admins can move member accounts freely between different OUs and are only subject to the policies of the OU they are under.
For example, an application could have its own OU that contains separate OUs for production and non-production accounts, as seen in Figure 1. Once developers have set up a member account in an environment under the non-production OU, that account can move to the production OU, which has more restrictive SCPs. At all times, the policies from the top-level account’s OU will apply. This ensures a granular level of control over the member account.
Figure 1. An example of nested OUs for production and non-production accounts
In AWS Organizations, the root OU is the top-level parent node for all accounts in an organization. When admins apply a policy to the root, all accounts and OUs within the organization adhere to that policy.
Most tasks that would normally require the root user can be done from the management account. So, why not disable the root user in your member accounts altogether?
Disabling the root user won’t affect the management account, since SCP doesn’t affect the management account. It will also force you to create users and roles with more limited privileges for each member account. In this way, it gets you a step closer to following least privilege when managing AWS services.
Since the root user has access to all AWS services by default, and some tasks can only be done with the root user, it can do a lot of damage to your account if it’s compromised. Add an SCP to the root OU in your organization to deny all API calls made by the root user.
