Multiple AWS Environments and Accounts – IAM Strategies

How many AWS top level Accounts should you have?

Here are some popular answers:

1. ONE Account – that encompasses all environments. Delineated access to Production and Non-Production occurs through IAM Groups (a separate NONPROD group, a separate PROD group…)
2. TWO Accounts – One for PRODUCTION and one for NON-PRODUCTION
3. MANY Accounts – One for each DEPARTMENTAL UNIT, so each group’s apps are compartmentalized.

None of the answers above is incorrect. However, each option comes with it’s own set of trade-offs. This post discusses the trade-offs to these popular multi-account strategies, especially from the Identity and Access Management perspective.

(Notice that the question wasn’t ‘How many VPCs should you have? As best practice dictates, you need at least two (One PRODUCTION and one NON-PRODUCTION VPC) to go hand-in-hand with AWS accounts).

Exploring the 2 AWS Accounts Option (1 PER VPC)

Creating separate AWS accounts for each environment (NON-PRODUCTION, PRODUCTION) – helps create a strong separation between the environments. The trade-off, of course, is operational challenges.

1. You need to re-create IAM users, groups, and policies under each account.
2. Employees who need to work in all three environments are required to sign in to each account separately.
3. Billing Consolidation – Your application is effectively running under three different accounts; you may need to consolidate billing across the three accounts to get a true picture of your application hosting costs. AWS Organizations is a new service that can assist with this aspect.

If you are still keen on using multiple accounts (one per environment), AWS offers a couple of options to avoid password ‘fatigue’. These options are Federated Access to AWS Accounts and Delegated API Access. These are briefly described below:

• Federated Access to AWS Accounts – AWS lets you tie your existing corporate identity (e.g., Active Directory) to IAM – allowing AD users to authenticate just once. Once authenticated, they have access to all the AWS accounts that their AD user is a member of. This is also known as Federated access to the AWS Management Console (since your identity is ‘federated’ from your corporate AD to AWS).
• Delegated API access allows an IAM user access to other accounts on a temporary basis. This is convenient and requires no corporate AD access from AWS.

Both of these options can assist with the biggest challenge of multiple accounts; i.e. users typing in multiple passwords to access multiple environments.

Exploring the Single AWS Account Option

Instead of an account per environment, the other alternative is to use a single account and leverage IAM groups and permissions to manage STAGING, PRODUCTION and DEVELOPMENT environments. This simplifies the task of managing users and permissions and more importantly, reduces complexity for the end users who need to work with multiple applications in different environments. However, there are some AWS resources that cannot be maintained using this ‘one IAM umbrella’ approach.

• For AWS S3, Amazon RDS or other AWS services that support resource-level permissions, you can extend your permissions management scheme to include those services under a single account.
• ELBs and AutoScaling, currently do not support resource level permissions. For these, you may be stuck with granting admin users full access to all environments – OR resort to Approach 1 (Separate Accounts).

In summary, the single account approach needs IAM Groups Combined with Resource Level Group Permissions, in order to work effectively. In addition, individual instances may need to be tagged appropriately (for e.g PROD-DB-1, DEV-DB-1) to distinguish the environment to which they belong.

Exploring the AWS Organizations Option

AWS Organizations is a service offering that lets you define OUs (similar to AD) and multiple users (accounts) under an OU.  Organizations provide full control over the AWS services and APIs that each member account can access.

AWS Organizations give you the best of both worlds – multiple accounts – and a centralized management account – which presides over the individual multiple accounts. It essentially works like an AD-like Tree structure; you have a top level OU (Organizational Unit) and multiple users under that OU.

More importantly, it provides you with:

1. Consolidated Billing – This is probably the number one use case for anyone doing multiple accounts.
2. Audit Purposes (PCI, HIPAA) Audit – Production Environment has restricted Access, which helps during any official audit. While most companies do not think of this up front, this is possibly the most important reason to go towards a separate PRODUCTION only account (and a top level Organization to manage it).
3. Control over AWS Services – u can create Service Control Policies (SCPs) that centrally control AWS service use across multiple AWS accounts. SCPs put bounds around the permissions that AWS Identity and Access Management (IAM) policies can grant to entities in an account, such as IAM users and roles. For example, IAM policies for an account in your organization cannot grant access to AWS Direct Connect if access is not also allowed by the SCP for the account. Entities can only use the services allowed by both the SCP and the IAM policy for the account.

Approach 4 – Exploring a separate Management VPC

Albeit not a common one, is actually, in my experience, a fool proof access strategy. The only drawback is that there might be some overhead in creating and maintaining a completely separate VPC.

The management VPC would contain Bastion Hosts, your hop points for each environment. You could have a single bastion host per environment (e.g. DEV hop box or PROD hop box) or a single one for each group of users (e.g. DBA hop box).

The only routes to your production VPC would exist from this management VPC – which would be peered with your environment VPCs . i.e. a peering between Management and Production VPC, another one between Management and DEVELOPMENT VPC and so on.

This approach has several advantages:

1. Utilizes AWS’ native networking constructs (VPCs) for delineation of environment access.
2. Single point of maintenance for all environments; This could support either SINGLE account (Approach 2) or Multiple Accounts (Approach 1) – for each environment.
3. Only need to harden the Management VPC. Since there is no direct way to get to the instances and services in other VPCs, the only VPC that needs to be hardened is the Management VPC.

SUMMARY

This is one of the most common cloud decision faced by companies. As per AWS (and Azure, GCP), best practice dictates that you provision (at least) two separate VPCs (VNETs on Azure); one for PRODUCTION and one for NON-PRODUCTION instances.

• Option 1 – Along with each VPC, ideally, you should have a separate AWS account. Using a separate account for your production environment can also help you pass compliance audits (e.g., PCI, HIPAA).
• Option 2 – If you want to have your cake and eat it too, a top level AWS Organization could be defined to manage the two separate accounts, and to provide a consolidated view of billing etc. for multiple accounts.
• Option 3 – Lastly, you could defined a completely separate VPC (a Management VPC) to isolate all access to your production and non-production environments. This has several advantages beyond the isolation.

Either of these three options listed above will help you manage multiple cloud environments, without compromising on the access management. .

Let me know your thoughts, experiences with similar multi-account strategies?