3 Ways to Manage Access to Multi-Account AWS environment

Recommended ways to manage Access to multi-account AWS environments

Photo by Miguelangel Miquelena on Unsplash

In the past, I have seen many companies managing AWS accounts access in different ways. A single AWS account with multiple VPCs for each environment (e.g. Development, Staging, and Production), some have separate AWS account per environment (multiple AWS accounts), some go further by separating AWS account per team (Account Factory)

There are many benefits why we should set up a multi-account AWS environment, but the major benefits are security control and simplified billing.

In this post, I wanted to discuss 3 ways I have seen companies manage access to a multi-account AWS environment.

1. Basic AWS IAM users per account
2. Dedicated AWS account with central IAM resources
3. AWS Single Sign-On

1. Basic AWS IAM users per account

Each account will have its own IAM users access, for example, Account1 will have IAM user john and the Account2 will have user john as well, there is no link what so ever, this setup is also how companies usually start when migrating to a multi-account set up as it’s easier to start.

To manage users, Terraform or CloudFormation can be used to create IAM users/groups/policies, or you can use a tool like IAMY.

2. Dedicated AWS Account with central IAM resources

Works by creating a new dedicated AWS account only for IAM users/groups next delegate access using IAM roles, there aren’t any other AWS resources in this account.

This central account will be the Identity Account and handles creating, managing, and tracking the IAM groups and users.

If your company name is acme you will end up with the following accounts:

• acme-development
• acme-staging
• acme-production
• acme-iam # Identity Account

There are many, many, many tutorials out there to start this kind of setup.

3. AWS Single Sign-On

AWS SSO is currently my recommended way to set up and grant access to a multi-account AWS environment. You can use AWS internal Identity source, MS Active Directory source, or any external SAML identity provider such as OKTA/OneLogin.

There are some prerequisites before you can start using AWS SSO:

• Setup AWS Organizations and have All features set to enabled.
• and invite other AWS accounts to the organization.
• enable AWS SSO using AWS Organizations management account credentials but remember to enable it on your AWS region.
• If you don’t use any external identity providers, then choose the default AWS SSO source
• Start creating users, groups and assign them to AWS accounts.

After setting up the AWS SSO root account, you can access all AWS accounts under one portal for example https://acme.awsapps.com/start

At the time of writing this blog, there are some limitations when using AWS SSO

• It is not possible to create users and groups using Terraform, Cloudformation, or even AWS CLI when using AWS SSO internal identity source.
• If one of your AWS Accounts is PCI DSS Compliant, then you cannot use AWS SSO to access the PCI DSS compliant account as AWS SSO is not in scope.

Update: As of ‘Feb 14, 2022' AWS SSO is now PCI DSS compliant 🥳

What if you are building a new AWS environment/Accounts from scratch? What if you are migrating from a single account to a multi-account?

I recommend checking out AWS Control Tower. Control Tower helps you create and manage a multi-account AWS environment with best practices.

What About You?

What kind of AWS accounts environment that you prefer or using right now?

Like this article? please consider following me on medium billhegazy, if you have any questions or would like to reach out, add me on LinkedIn