How to manage your AWS accounts?

It is common to use multiple accounts in AWS to split up environments, group workloads based on the business function, or apply tighter security measures…

That’s a correct way to do it, but it comes with the pain and overhead of managing multiple AWS accounts. Should we create a user per account for each of our users? Should we set up a different payment method by account?

Photo by qimono on Pixabay

AWS solves this problem for us through “Organisations”. AWS organisations help govern and manage multiple AWS accounts from a centralised place, simplifying billing and configurations and making scaling your business effortless.

How to create and configure your org?

From one of your standard AWS accounts, you can create an “Organisation”. This makes that standard account the Organisation Management Account. You can only have a single Management Account in an organisation.

What about the rest of the accounts? You can invite them from the management account into the created organisation. This makes them “member” accounts (Note that these accounts need to accept the invitation).

The AWS organisation is hierarchical and is formed of an Administrative Root and one or more Organisational units. The Administrative root is the highest level container of the organisation (it contains AWS accounts and other containers). An Organisational Unit is a group of one or more AWS Accounts within your organisation. For example, you might choose to have 2 Prod accounts to separate the infrastructure of 2 entities within your product but would want to only keep one for Staging and one for Dev. One way to go about it is by creating 3 Organisational Units, one for Dev, one for Staging, and one for Prod. The latter contains 2 AWS accounts.

Below is one way to visualise the previous example:

For our example, I will work with two existing accounts only, one the management account and the other the member account.

The terraform configuration would look as follows:

resource "aws_organizations_organization" "org" {
  feature_set = "ALL"
}
resource "aws_organizations_organizational_unit" "prod" {
  name      = "prod"
  parent_id = aws_organizations_organization.org.roots[0].id
}

Once you apply this Terraform, you would need to verify the root email of the management account.

Unfortunately, I did not find a way to invite an existing account to an organisational unit using Terraform. So I’ve done this manually from the console:

Once the invitation is accepted, select the account, click “Actions”, and move it under the “Prod” organisational unit.

Also, it is possible to create a new account from within an organisation. This would skip the invitation process.

We have an organisation, an organisational unit, and two accounts. What can we do next?

It’s time to solve the two problems we mentioned: setting up billing for each account, creating users and assigning roles per account.

Consolidated Billing

As simple as it sounds, the “consolidated billing” feature removes the billing from the member accounts and keeps only the billing on the management account. You will get a single bill covering the management and member accounts. Another benefit of using consolidated billing is that of possible discounts offered on the usage of certain services. This discount would now apply to the combination of the usage of these services within the accounts of the organisation.

Looking at the terraform code above, notice the feature_set key set to ALL. This includes the consolidated billing features. More information can be found at: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org_support-all-features.html

Users Creation

With organisations in place, there is no need to create users in every account. Instead, we create a new AWS account to handle identity. Users access this account and switch roles to the other accounts as needed — assuming a role in the accessed account. This is especially great as it helps apply the Least Privilege principle.

This involves more work than the consolidated billing, so here we go.

Apply the following config to create a new AWS account:

resource "aws_organizations_account" "identity_account" {
  name  = "identity"
  email = "yourEmail@email.com"
}

In the AWS console, under Organisations, note the ID of the newly created Identity account.

Prod Account

Now we need to log in to the Prod account we added to the organisation and create a role that the Identity account can assume. In the AWS Console in a new browser session:

• Navigate to IAM and create a new role as follows:
• Enter the Identity account Id noted earlier.
• In the second screen, select the policy we’d need to attach to this role. Select the Administrator Access policy

• On the third screen, enter the role name and click Create Role (Note that the account created by AWS from within the organisation will automatically have this role created with the following name: OrganizationAccountAccessRole. Feel free to use that same name for the role we just created)

Identity Account

Now you might wonder how I will log in to the Identity Account. We just created it from within the organisation, so there is no email and password to use 🤔

From within the management account we’re already logged in to, select the account name on the top right corner, and click “Switch role”:

Fill in the details, and you’re now inside the Identity Account — The Identity Account users will use this same method to navigate to the Prod Account. But there are a few tiny steps to finish.

In the Identity Account, create a User Group called Developers and assign to it this inline policy:

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

Create a user and add it to that User Group. Users can switch roles to access the PROD account when they log in. Isn’t that fascinating?

All that’s left to do is tighten the permission given on the prod account role that is assumed to match the least privilege principle.

Of course, there are many improvements to add and many questions to answer. How can we create and apply my infrastructure as code? Would it still go directly to each account, or would it also go through role assumption? How would we switch roles when we log in from the command line?

I’d be keen to hear your thoughts.