PHANTOM DEV

PHANTOM DEV

AWS Organizations and Multi Account Access

AWS Organizations and Multi Account Access

Subscribe to my newsletter and never miss my upcoming articles

AWS Organizations and Multi Account Access

07 Jun 2021 | 2 min read

What is an AWS Organization?

AWS Organization provides the tooling required for engineering teams to manage and govern their AWS stack effectively.

Key features

  1. Ability to configure sub-accounts
  2. Define grouped accounts ie. Dev, Staging, QA with individual user accounts
  3. Ability to use centralize governance and access control to switch onto sub-accounts or assume the role of a sub-account programmatically depending on the use case.

Below, we will discuss a hypothetical scenario on how we can configure and use sub-accounts with AWS Organizations.

Scenario

Pied Piper is a small start-up with a few engineers. Currently, they have all of their resources in a single AWS account. Given they are entering a high-growth phase and also they want to be on top of the recommended AWS best practices they have to restructure how they consume AWS. In order to do this, they will take the following steps. It's important to note that this is one of structuring the resources and it's not the only way.

Step 1

Define the team structure

Step 2

Define the AWS Account Hierarchy

  1. Root / Master Account - This is the main AWS account of the company
    1. Dev Account - Team A
    2. Dev Account - Team B
    3. QA Account
    4. Staging Account
    5. Production Account

Step 3

Optionally implement the infrastructure as code. This is optional because you can get away with it for a while although it's not scalable. But is recommended to use a tool like AWS CDK, Terraform, Pulumi to make sure the teams can easily replicate the infrastructure in each account.

Step 4

Enable cross-account access. There are few ways to do this, for this scenario with Pied Piper, we will structure the cross-account access the following way

Root / Master Account

This account will. serve as the "Security / Management" account and we will create and manage all our IAM users, Roles and Policies required.

For instance, IAM User for Team A and a Role. A policy that will allow the IAM User for Team A to assume a role. In the below example we just give blanket permissions to all the sts actions on any resource.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "sid-for-this-policy",
            "Effect": "Allow",
            "Action": "sts:*",
            "Resource": "*"
        }
    ]
}

The admin can switch roles into each sub-account using the following URL ff

signin.aws.amazon.com/switchrole?roleName=O..

When AWS creates a sub-account using AWS Organizations we have a default Role OrganizationAccountAccessRole this gives access to the sub-account and assumes the pre-defined policies in the AWS Organization. The admin can either create different roles for each of these accounts and pass them onto the individual user's Team A, Team B, and QA

Cross-account access is not limited to Parent-Child account, if the policies are configured we are able to give access to Sibling accounts as well. For an instance, the QA account can be accessed by Devs and viseversa.


To summarise, AWS Organizations will give Engineering teams a better structure of their AWS Workload. Separate Production from Development, QA, and Staging environments. Have a separate space to manage access to these resources in a centralized manner.

References

https://aws.amazon.com/organizations/

https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.pdf

https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html

https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_access.html

https://aws.amazon.com/premiumsupport/knowledge-center/iam-assume-role-error/

#aws

← How to configure VPC Peering on AWS in 5 min Docker CMD vs ENTRYPOINT →

 
Share this