Managing multiple accounts with AWS Organizations

Eden Project Dome
Image by User:qubex from common.wikimedia.org / CC BY-SA

It’s desirable to use separate AWS accounts to enforce isolation between environments. For example Staging and Production should be in separate accounts in order to limit risk when deploying applications and creating or upgrading infrastructure.

However, managing multiple accounts leads to operational complexity. IAM users, groups and polices need to be created under each account and billing is complicated by having to manage spend and payment methods for each account individually.

AWS Organizations is a service to centrally manage creation, billing and access to AWS accounts.

Creating the Organization

An organization encapsulates multiple AWS accounts which you can manage from a single account. The organization should be created with the account you want to manage the organization from. You can create an organization from the AWS console or using the CLI:

aws organizations create-organization --feature-set ALL

You can set the enabled feature set to all features (“ALL”) or consolidated billing (“CONSOLIDATED_BILLING”). If omitted the default is ALL which at time of writing consists of consolidated billing and the ability to apply policies to accounts which will be touched on later in this article.

If you want to enable all features after creating the organization any member account that was invited will need to approve the request. This doesn’t apply to accounts created under the organization.

Creating Accounts

AWS Organizations define two types of AWS accounts - management and member. The management account is the account that creates the organization and from which other accounts and organization policies are managed. Other accounts belonging to the organization are referred to as member accounts. An account can only belong to one organization at a time.

Using your management account, you can create member accounts from the organization section of the AWS console or using the CLI:

# Create a staging account with a root account email address of
# staging@example.com. The email address must be valid.
# Allow IAM users in the new account access to billing if they have the
# required permissions.

aws organizations create-account \
  --account-name fullback-staging \
  --email staging@example.fullbacksystems.com \
  --iam-user-access-to-billing ALLOW

Output:

{
  "CreateAccountStatus": {
    "Id": "car-c03bd870bb4011eabda812c69f0a0f79",
    "AccountName": "fullback-staging",
    "State": "IN_PROGRESS",
    "RequestedTimestamp": 1592444656.378,
  }
}

You can check to see if the account was successfully created using the account request id returned in the output

  aws organizations describe-create-account-status \
    --create-account-request-id "car-c03bd870bb4011eabda812c69f0a0f79"

Output:

{
  "CreateAccountStatus": {
    "Id": ""car-c03bd870bb4011eabda812c69f0a0f79",
    "AccountName": "fullback-test",
    "State": "SUCCEEDED",
    "RequestedTimestamp": 1592444656.378,
    "CompletedTimestamp": 1592444660.24,
    "AccountId": "920433668570"
  }
}

When you create an account a new root user for the account is created with the email address you specified. When logging in to the AWS console using the root account for the first time use “forgot password” to set a password. As per AWS best practices do not use the root account for day to day administration.

Using Roles to Manage Accounts

Roles provide a convenient way to administer member accounts without creating additional IAM users or requiring users to sign in and out of multiple accounts.

On member account creation a role called “OrganizationAccountAccessRole” is created in the member account which can be assumed by IAM users from the management account. The role has full administrative permissions in the member account. To use this role to access the member account IAM users in the management account need to have the appropriate permissions configured.

The following example policy grants access to the role in two member accounts. Create and attach a policy to the group or IAM user you want to be able to assume the role.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": [
        "arn:aws:iam::920433668570:role/OrganizationAccountAccessRole",
        "arn:aws:iam::326635341555:role/OrganizationAccountAccessRole"
      ]
    }
}

You can switch roles from the AWS Console by clicking your username on the navigation bar in the upper right and selecting “Switch Role” from the menu.

The AWS CLI supports switching roles through CLI profiles. In The following example a CLI profile is configured to use credentials from the management account to request credentials for the “OrganizationAccountAccessRole” role in a member account.

[profile fullback-staging]
    role_arn = "arn:aws:iam::920433668570:role/OrganizationAccountAccessRole"
    source_profile = fullback-management

It’s also possible to generate temporary credentials using the CLI. The following will return a json response containing temporary credentials for the “OrganizationAccountAccessRole” role in a member account.

aws sts assume-role  --role-arn \
  "arn:aws:iam::920433668570:role/OrganizationAccountAccessRole" \
  --role-session-name test-session

Inviting an Account

You can add an existing account to join an Organization by sending an invitation to the account owner either from the AWS Console or via the CLI:

aws organizations invite-account-to-organization \
  --target=Id=<account_id>,Type=ACCOUNT

The invitation must be accepted for the account to become a member.

Unlike accounts created using AWS Organizations, the invited member account won’t have the ‘OrganizationAccountAccessRole’ so the management account won’t be able to assume administrative access. The AWS documentation describes how to create the ‘OrganizationAccountAccessRole’ in an invited member account.

Policies

Policies in AWS Organizations enable you to apply additional control to the AWS accounts in your organization. You can use policies when all features are enabled in your organization. Policy types include:

  • Backup policies to create Backup Plans to use across your accounts

  • Tag policies standardise Tag names and values on resources across accounts.

  • Service Control policies are applied to member accounts to restrict IAM Principals capabilities within these accounts. For example restricting the types of EC2 instance that can be launched by an IAM user in member accounts. The documentation contains some example SCP’s.

  • AI services opt-out policies to opt out of having data you process by AWS AI services used by AWS to train and improve these services.

Organization Hierarchy

AWS Organizations provides the ability to group accounts together into Organizational Units (OU’s) which can have policies applied to them.

Organizations are structured as a tree with a single root node. Child nodes can either be accounts or OU’s. An OU is a container whose child nodes can be accounts or other OU’s. Each node can only have one parent and accounts must be leaf nodes.

The diagram below shows an organization that consists of five accounts. Four of the accounts are grouped under OU’s. The organization also has several policies that are attached to OU’s or directly to accounts.

Organization tree diagram

Policies can be attached to any node in the hierarchy and are applied to all descendant nodes. Since policies can be attached to multiple nodes, accounts may inherit multiple policies.

Trusted Access

Certain AWS Services can be configured to perform tasks in your organizations accounts from the member account by configuring trusted access.

Some example applications include:

  • Deploy CloudFormation StackSets across all organization accounts or specific OU’s.

  • Create a CloudTrail trail to log events for all AWS accounts in the organization.

  • Monitor AWS Backup jobs across all accounts in the organization.

Conclusion

AWS Organizations tames the complexity inherent in managing multiple accounts. Policies provide a mechanism for you to restrict the actions of Principals within those accounts as well as standardise Backup Plans and Tagging. Organizational Units provide the ability to selectively apply multiple policies to groups of accounts and Trusted Access gives the ability to perform operations across the organization from the management account.

If you would like to discuss AWS Organizations or any of your infrastructure needs please feel free to contact me at anthony@fullbacksystems.com.