5 Tips for Starting Your Organization with Multiple AWS Accounts

They say the more the merrier – and that holds true for accounts on AWS. While most companies starting out on AWS start with a single account, AWS recommends creating multiple accounts as a form of best practice when workloads and infrastructure become more complex. Multi-account environments in AWS are becoming the standard for organizations with mission-critical resources in the cloud, and multi-account management is an often overlooked skill that is increasingly in-demand.

In this blog, I explore the reasoning behind multi-account environments. And I'll provide a few tips to help you, the systems administrator, avoid common pitfalls in setting up your organization.

It may surprise you to hear that it’s entirely possible to run a perfectly secure, mature, and complex set of AWS resources out of a single AWS account. Yes, it’s true! IAM policies are infinitely customizable, and access can be controlled at an insanely granular level. Tags can be enforced, and single-account service limits can (usually) be increased. 

But as our AWS environments get more complex in a single account – as we mingle our production resources, with our development resources, with our monitoring resources, with our security resources – the effort needed to maintain least privilege access, and the cost of human error, inflates exponentially. One misconfigured IAM policy or one compromised set of credentials, and bad actors could have access to your entire AWS landscape. As an analogy, think about the evolutionary leap needed to sustain single-cell organisms compared to multicellular plants and animals - with the latter requiring more sophisticated and coordinated processes and tools to keep everything functioning.   

This is where a multi-account environment comes into play. Leveraging multiple accounts can greatly reduce the complexity of keeping your mission-critical resources secure. By acting as a coarse filter for access to resources, accounts make it much easier to maintain “least privilege” access standards. They can also reduce the blast-radius if a set of access keys is leaked, or some similar security event. There are other latent benefits, such as simpler billing visibility on collections of resources, and avoiding single-account resource limits on services such as Lambda and Amazon VPC.

It’s easy to see the benefits of a multi-account environment. It’s also relatively easy to set one up, thanks to services such as AWS Organizations and AWS Control Tower. Unfortunately, this means it’s also exceedingly easy to set up your multi-account environment poorly, causing you and your organization pain down the road. Here are five tips to help you set up a future-proof multi-account environment.

• Tip 1: Plan ahead with email addresses
• Tip 2: Create a new AWS account to act as your management account
• Tip 3: Use AWS SSO
• Tip 4: Organize wide, not deep
• Tip 5: Don’t get ahead of yourself!
• Honorable mention: Use AWS Control Tower

Each AWS account must have a unique email address to act as the root user of the account. All too often I have seen personal email addresses used as root users for organizational accounts containing mission-critical resources. Bad idea! Those administrators move on to new opportunities, and access to the root user is lost to time; requiring cumbersome back-and-forths with AWS support to rectify. For each account you plan to have in your organization, consider the appropriate email address to act as the root user, and who should have access to that root email account (or listserv, or alias).

For your management account root user email, you may choose something like “aws-admin@example.com”. Depending on your email service provider, you may be able to use ad hoc aliases for other accounts. For example, if your organization uses Gmail, you could use something like “aws-admin+audit@example.com”. This alias sends all confirmation emails to “aws-admin@example.com”, but still acts as a unique email in the eyes of AWS for account provisioning. Carefully consider your organization’s needs and don’t ignore the importance of intentionally choosing and controlling access to your root user email addresses!

It may seem intuitive to use your main AWS account as the management account for your organization. But access to your management account – and activity within your management account – should be reduced as much as possible. It is considered best practice to avoid workloads of any kind in your management account.

The easiest way to achieve this is to create a brand new account to act as the management account. After creating your organization from the management account, you can invite your existing account(s) as member accounts.

One of the great challenges of managing multiple accounts is that human access to your accounts is decentralized by default. If you’re used to giving people access to your account via IAM Users, the prospect of managing users across many accounts may seem intimidating. Luckily, AWS provides a simple solution for multi-account identity federation and access management, which can all be administered from the management account.

AWS SSO leverages your existing identity provider (such as Azure AD or Okta) to help you map users or groups to IAM permissions sets in each of your accounts. It can also act as its own user directory if you do not have a third-party identity provider. Use AWS SSO and delete all (yes, all) of your IAM Users!

As you set out to organize your AWS accounts, you’ll be tasked with grouping your accounts into Organizational Units (OUs). The rule of thumb is to organize your accounts based on their security and operational needs.

Generally speaking, security guardrails are applied to OUs and inherited by accounts under that OU. If two sets of accounts have similar, but not identical security needs, it may be tempting to create nested OUs. The “child” OU could inherit all guardrails from the “parent”, and then additional guardrails could be added onto the child. This is not advisable, and in most cases the better solution is to create a separate, “sibling” OU. Because these sets of accounts have different security or operational needs, it’s hard to tell if their future guardrails will always follow the parent-child inheritance pattern that they currently do. To avoid complex dependencies, it’s best to keep these OUs as siblings.

If you’re like me, it’s very easy to get excited about the many possibilities for building out your AWS environment. At times it may feel like you have to know everything before you can start to move forward. But just like any technical solution, account structures can be over-engineered to the point whre they’re getting in the way, more so than they are enabling your organization to move quickly. Make sure you understand the fundamentals, and don’t skimp on adhering to best practices for AWS security, operational excellence and cost control, but also – don’t let perfect be the enemy of the good. 

When creating and organizing accounts in AWS, try not to do more than you can currently benefit from. In this line of work, you’ll always be learning new and better ways to do things. Your opinion today is almost never as good as your opinion tomorrow!

In most cases, I recommend using AWS Control Tower to administer your multi-account AWS environment from the very beginning. Control Tower encompasses too much to capture in this short blog post, but I encourage you to explore the service and consider it for your account administration.

AWS Control tower automatically provisions AWS Organizations and AWS SSO. On top of that, it gives you a selection of powerful, automated tools to help you follow the best practices for multi-account management. 

As you can see, managing multiple accounts involves knowledge of many services across AWS, which can make starting a multi-account environment scary to approach for new AWS systems administrators. I hope these tips have provided you with some of the context and confidence you need to take on all of your multi-account challenges! For more information on the tools and best practices for organizing accounts in AWS, or if you want an in-depth look at the services involved in AWS Control Tower, check out my course How to Organize Your Accounts in AWS.

Learn faster. Move faster. Innovate faster. A Cloud Guru is the key to your success. Transform now with courses and real hands-on labs in AWS, Microsoft Azure, Google Cloud, and beyond.