Getty Images/iStockphoto
Implement these 4 AWS Organizations best practices
To successfully use AWS Organizations, admins must grasp key concepts related to organizational units, service control policies, and management and member accounts.
Running multi-account environments in AWS can be difficult. Fortunately, AWS Organizations provides a way to centralize control, organize accounts, consolidate billing and limit what users can do in those accounts.
While it does simplify multi-account management, the service is not without some challenges. Certain best practices, such as using organizational units with service control policies and knowing which account types to use, can help IT admins use AWS Organizations effectively.
Use OUs to manage member 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, imagine you manage an AWS account for an application that only uses EC2 and S3. You run separate member accounts for each environment such as development, production and testing. 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 imagine 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.
Separate the management account and member accounts
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.
Key terminology
To better understand AWS Organizations, here are some helpful terms and concepts from AWS documentation.
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.
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.
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.
Move accounts between OUs when needed
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.
Restrict the root user in member 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.
