An Overview of AWS Organizations

For enterprises with multiple accounts, we can link accounts together for billing purposes through Consolidated Billing. With AWS Organizations we can now move beyond Consolidated Billing and create multiple accounts, group those accounts according to organizational units, and invite existing accounts to link to the Master account.

This article examines AWS Organizations, what it is, why you want to use it, and how to get set up.

AWS Organizations allows you to create an organizational structure for your accounts, so you can organize accounts into groups and apply policy, security and compliance requirements across the entire organization or individual organizational units (OU).

When an enterprise is using multiple accounts outside of AWS Organizations, Service Control Policies have to be managed individually for all of the accounts, possibly resulting in misconfigurations across those accounts and either providing access to services or data which should otherwise be restricted. This control is simplified in AWS Organizations, meaning all of the accounts can be centrally managed, ensuring compliance with your organization’s policies, while controlling access to specific AWS services.

We can also configure how AWS Services are configured across all of the accounts, meaning unless there are specific needs for an account, those services will all function the same in each account.

Finally, consolidated billing means all of the charges for each account are billed against the master account, allowing you to take advantage of volume discounts which might otherwise not apply at the individual account level.

It is remarkably easy to set up AWS Organizations. In the console, navigate to the AWS Organizations page and click on the button to set up AWS Organizations.

Once the organization is set up, the view resembles this.

Image for post

By default, failed account creation requests are not shown, and this can be changed by toggling the button to hide or show them. Making the failed requests visible is reset every time you access the main view.

Image for post

The main view allows you to create additional accounts, view the details for a given account, see organizational units for that account, and applied policies. Policies cannot be attached to an account until the policy has been applied to the root of AWS Organizations.

There are two ways of adding accounts to the organization. The first is to create a new account, and the second is to invite an existing account. When you click on the “Add Account” item on the AWS Organizations dashboard, you are prompted to choose which option. We are going to examine both of them.

After selecting to Create an Account, a dialog appears with the information needed to add the account.

Image for post

Complete the fields and press the “Create” button. It can take a few minutes for the account creation process to complete. Once it is complete, the account email and ID appear in the table.

The alternative to creating a new account is to invite an existing account to join the organization.

When inviting an account, select “Invite Account”, which prompts you to enter the account ID of the account you want to invite, and an opportunity to enter a message. Adding a message is important as the target account is notified of your request and must agree to join the organization.

Image for post

The target account receives an email advising of the invitation, and it is up to the owner of that account to accept or reject the invitation.

Image for post

The target account owner can click the link in the email to accept the invitation, or access the request through the AWS Organizations service in the console. Accepting the invitation involves reviewing the request, confirming to join the organization, and being notified when the invitation has been accepted and completed.

Once the invitation has been accepted and completed, the target account owner is notified via email, and their view in AWS organizations changes to show they are now part of the organization.

Image for post

The master account view also changes to show the new accounts added to the organization. There is, however, no way to know which accounts were added through an invitation and which were specifically created.

In AWS Organizations, we can group accounts into Organizational Units, and apply policies specific to those accounts.

Image for post

The tree view on the left shows all of the configured organizational units, while the main section shows the accounts and OUs in that view, and the right side contains the view details, including the Service Control Policies attached to the OU.

To select an account, click on the account box. When the account is selected, you can move it to another OU, except for the root account.

To select an OU, click on the OU box which displays the accounts and organizational units for that OU.

Image for post

One might argue the Service Control polices form the heart of AWS Organizations. When the organization is initially defined, there is only one policy associated with the accounts, “FullAWSAccess”.

Image for post

Clicking on the Policies item in the navigation section displays the page where you can create, edit and delete policies, view their details and see the accounts and organizational units attached to the policy. By default, the FullAWSAccess policy is not associated with any accounts or organizational units. Selecting a specific policy shows the policy details on the right-hand side of the view.

Clicking on the “Create Policy” shows the policy creator. Service Control Policies (SCP) define the maximum permissions the account can have for that service, but the SCP does not grant permissions to the service — you still need to define IAM permissions for the service, resource or user.

It is important to note you can only create Service Control Policies if all of the AWS features are enabled. If you are only using the Consolidated Billing Features for your account, you cannot define or apply Service Control Policies.

When an SCP is defined for a service, it establishes the maximum permissions for that resource. When permissions are granted in Identity and Access Management (IAM), the specific permission is only granted if it is allowed by the SCP.

Image for post

The Policy Editor is a visual editor where you can select the service and define the maximum permissions. Using the editor is the recommended method for defining a new policy.

WARNING: Do not apply a policy to your root account or organizational unit without first testing it on a specific account to validate the results are what is expected. Doing so may result in your inability to execute the needed actions in your account.

For example, let’s assume you want to deny a specific service to your organization for some reason. For our example, let’s deny access to DynamoDB.

Enter a name and description for the policy, and then navigate through the service list on the left to find ‘DynamoDB’. After selecting DynamoDB, a list of actions is displayed. If you want to deny specific actions, select those, but for our example, we are going to deny all actions in DynamoDB, effectively removing an account’s ability to access the service.

Before we can submit the policy, we have to select the resources to apply the policy too. In this case, we want to apply this policy to DynamoDB.

Image for post

We have to select DynamoDB as the service, select all of the resources, and because we are opting to deny DynamoDB completely, leave the ‘*’ in the ARN field.

Once we have defined everything in our SCP, the resulting JSON looks like

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Statement1",
"Effect": "Deny",
"Action": [
"dynamodb:*"
],
"Resource": [
"*"
]
}
]
}

This has the effect of denying all actions associated with DynamoDB.

As mentioned previously, we should not apply this policy against the master or root account until we are sure it provides the desired result. Once we have validated the result, we can apply the SCP to the appropriate OUs or accounts.

Before we apply this policy to all of our accounts, AWS recommends verifying you get the desired result before implementing it everywhere.

First, let’s validate the other account can access the resource we are going to block, in this case, DynamoDB. We do this by logging into the master account, and using the switch role feature to switch to the target account.

Image for post

If you have never switched roles before, click on the “Switch Role” item, which displays this page:

Image for post

You have to enter the target account ID, and the target role, which is the “OrganizationAccountAccessRole”, which was created in the target account when the organization was defined and the target account was linked to the master account.

Because I have already accessed the other account using the Switch Role function, it appears in the Role History above the Switch Role item. After you switch roles, the view in the target account matches where you were in the console in the original account. For example, because I was in AWS Organizations when I switched roles, I am in the same view after switching roles.

Image for post

Let’s go create a table in DynamoDB.

Image for post

With our table created, we can see the table details.

Image for post

Now, let’s go back to the Master account and apply the DenyDynamoDB policy.

Before we can apply the Service Control Policy, we have to enable this feature on the root or master account.

Image for post

Click on “Enable” next to Service Control Policies to enable SCPs on the root account. This shows Service Control Policies are enabled, and we can add our policy to our target account by selecting the target account in the view, and then clicking on Service Control Policies on the right side of the page.

Image for post

After clicking on “Attach”, the SCP is attached to the account, and when we access the alternate account, we should not be able to access DynamoDB now.

After switching roles, and accessing DynamoDB, we are presented with the DynamoDB Getting Started page. Click on the arrow at the top left of the page.

Image for post

When we click on the Tables item on the left of the page, we get an access denied message because the Service Control Policy is in place. All DynamoDB actions are denied at this point, making usage of the service for this account impossible.

Image for post

If this is the desired action for all of the accounts in the organization, then applying the policy to the root account will apply the policy to every account in the organization.

The principal thing to remember with Service Control Policies is to attach them to an Organizational Unit and not to account. By attaching the SCP to the OU, the SCP is propagated to every OU in the hierarchy.

The second key point is that SCPs define the maximum permissions for the service. Even if an IAM Role or user has more extensive permissions, they will not be granted to the user or role because of the SCP.

The Settings view allows you to view the details for the organization, including the master account information and the trusted services configuration. Trusted services can access information about the accounts, OUs, polices for the organization.

AWS recommends adding the desired trusted services to the account using the console so other tasks that must be performed to enable the access are also performed.

At some point, it may be time to remove an account from the organization. To do this, go to the AWS Organizations dashboard view, and select the account. At that point, you can remove the account.

This is best done from the account leaving the organization, as it may be necessary for additional information such as contacts and billing information to be provided.

There is no cost to using AWS Organizations itself, but any resources created in the accounts associated with the organization may incur charges as defined in the pricing structures for those services.

If you are considering the use of AWS Organizations, it is advisable to develop either parameterized CloudFormation templates or a custom application using the SDK to add/remove accounts in the organization.

The advantage to this becomes clear as you add Service Control Policies to control and limit the maximum permissions for various AWS Services, or as illustrated in this article, prevent the use of a service altogether. This way you can ensure when accounts are created, the process is consistent, they can be assigned to an OU, and the appropriate SCPs are applied immediately.

This is a topic for a future article, but it needs to be mentioned in this context.

Designed to assist organizations to create, manage and control a multi-account AWS environment, Control Tower helps by applying the best practices established by AWS through their experience in supporting organizations as they migrate to the cloud. According to the product webpage AWS Control Tower “can provision new AWS accounts in a few clicks, while you have peace of mind knowing your accounts conform to your company-wide policies”. I will dive into AWS Control Tower in a future article.

Here are some things to consider when getting ready to move beyond your one account and start setting up AWS Organizations.

You must give serious consideration to how you will get organized. There are several options: — Organize by functional domain. Just like we organize people and process your function, we could do the same for accounts.
— Organize by development phase. You may want an account for developers, along with corresponding VPCs for development and testing, along with a separate account for production. This eliminates the separation of duties issues by ensuring users with access to the development account can not access the production account. — Organize based on data classification. This is another situation where you may need to create OUs for your most sensitive information, regardless of which part of the organization.

Image for post

What works in one situation, may not work for another. I would suggest creating OUs based upon business function. For example, finance apps and users are in the finance OU, and each OU has several accounts, one for each of the development phases, and one for production. This has the benefit of keeping the applications and data for that business unit together.

For example, general ledger and related functions would be used by finance users, and typically no one else in the company. Those same functions are likely implemented in software and need to communicate with each other, by keeping them in the same OU and different accounts for development and production, you can limit who has access to this important resource.

Aside from denying specific services such as our DynamoDB example earlier in the article, you may also want to consider Service Control Policies extricating what actions can be taken for the security and IAM services. The important thing to remember is you will have to decide what is allowed and not allowed within your specific organization and it’s specific rules and legal obligations.

For example, you may want to prevent users from disabling services like CloudTrail and CloudWatch, prevent configuration changes on services, prevent VPCs from getting internet access, etc. AWS has defined several scenarios and provided sample Service Control Policies to implement them. These are worth examining and applying to your organization if they make sense.

Some additional best practices to consider when setting up AWS Organizations: — It is strongly recommended you do not create any resources (with one exception) in the Master account. This makes it easier to make high-quality control decisions, and make it easier to understand the charges on your AWS invoice. — The one exception is CloudTrail. You should set up CloudTrail in the Master Account so you can track all AWS usage across the member accounts.
— Every account/OU should be set up to have the least privilege possible, even if you are going to further reduce the privileges using IAM. For example, users who are in the development OU should not have access to the production VPCs and OU. Even then, you may want to limit who can create, modify and delete resources.
— Assign Service Control Policies to the OU rather than the accounts. This allows for a better mapping between the organizational structure and the level of access needed within AWS. — After creating a new Service Control Policy, validate operation in one account before implementing it across all of the OUs. This makes it easier to rollback should the result be something other than anticipated. — Automate the creation of accounts. Create a CloudFormation template so every new account is created and configured for the organization. This template can create the account, assign to an OU, attach Service Control Policies, create VPcs, IAM roles, etc. Just as we implement resources using infrastructure as code (e.g. CloudFormation), so should we consider the creation of an account and OU as a similar process.

AWS Organizations can be invaluable to enterprises who need multiple accounts to segregate work, and apply either unique SCPs to an account, or more specific IAM roles for specific use cases. It also provides consolidated billing through the master account, so volume discounts can be achieved which might otherwise not be attainable at the individual account level.

Additionally, using multiple accounts also allows for the separation of development, test and production environments aside from VPC separation, as more granular control can be achieved at the account level through IAM roles than at the VPC level.

Enabling additional trusted services, and simplifying logins to the organization through the AWS Single Sign-On (SSO) service is also possible.

In conclusion, using AWS Organizations is a must for anyone needing more than a single account or VPC and is a best practice for managing the services and resources in your AWS environment.

AWS Control Tower

AWS Organizations

AWS Organizations Tutorials

Enabling All Features in your AWS Organization

Example Service Control Policies

IAM JSON Policy Elements: Condition

Managing the Accounts in your AWS Organization

Service Control Policies

Strategies for using Service Control Policies

Chris is a highly-skilled Information Technology AWS Cloud, Training and Security Professional bringing cloud, security, training and process engineering leadership to simplify and deliver high-quality products. He is the co-author of more than seven books and author of more than 70 articles and book chapters in technical, management and information security publications. His extensive technology, information security, and training experience makes him a key resource who can help companies through technical challenges.

This article is Copyright © 2019, Chris Hare.

Written by

Chris is the co-author of seven books and author of more than 70 articles and book chapters in technical, management, and information security publications.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store