How Many AWS Accounts Do I Need?
In AWS it’s common to have many AWS accounts. Large enterprises may have hundreds or even thousands of accounts. In this post I’m going to discuss why it makes sense to have multiple accounts, where to draw the line of ’too many' accounts, and how to manage them.
What’s wrong with having everything in a single account?
When deciding on any sort of strategy, it’s important to have clear reasoning and goals behind what should be achieved.
There are a number of reasons why a multi-account configuration makes sense in AWS.
Reduce blast radius
This is a key reason for adopting a multi-account AWS set up. When accounts are shared, even with the most comprehensive IAM policies to restrict the actions of account users as much as feasible, it is perfectly possible for an action to inadvertently cause an outage for the entire account.
One example of a situation that could lead to account-wide problems are AWS account quotas being hit, for example the limit on the number of Elastic Network Interfaces in an account, or the maximum number of RDS instances. Another is accidental resource exhaustion, for example deployment of a Lambda function which triggers itself, causing an infinite loop and preventing any other Lambda functions from being invoked.
It is inevitable that such problems will occur at some time; by adopting a multi-account strategy, we can at least ensure that the scope of the problem is limited as much as possible.
Simplify configuration
The goal of simplification is an important one to keep in mind when evaluating which choices we make. Implementing a multi-account strategy introduces much complexity around account creation, organization, cross-account connectivity and permissions.
Not implementing a multi-account strategy also introduces much complexity, or otherwise introduces significant risk. To work in a safe and secure a manner in a shared account we would need to implement organization wide tagging policies, write elaborate IAM policies to prevent teams from being able to modify resources they are not responsible for, and implement strict change control to avoid teams causing the types of outages alluded to in the ‘Reduce blast radius’ section above.
Cost Attribution
Depending on how accounts are organised and the level of detail required, cost attribution in a multi-account configuration can vary between ’trivial’ and ‘relatively simple’. Because AWS provides separate bills per account costs are already allocated in a way that should make sense for your organization. If further detail it required, it is significantly easier to slice this bill further than it would be to interrogate all entries for every team in your organization.
How many accounts are too many?
When deciding on a strategy, it’s important to balance complexity. Too few accounts will create additional complexity, but so will too many.
Writing cross-account IAM policies can be challenging, and it makes sense to avoid direct access of resources across accounts as much as possible. There may be places where this is necessary - for example centralized S3 buckets. In these cases, I would suggest writing policies that utilize Organizational Units to allocate permissions as much as possible, making it easy for permissions to be added to newly created accounts.
Suggested approaches
Separate development and production accounts
It makes sense to keep production and development environments in separate accounts. There are a number of advantages to this approach:
Limit access to confidential data
Production accounts may contain sensitive data, including personally identifiable customer data which has legal requirements for ensuring the correct handling of such. Splitting accounts into production and non-production makes it simple to know where such data should be, and to utilise tools such as Amazon Macie to alert on the discovery of sensitive data in the wrong environment.
Increased application reliability
Having a separate account for non-production allows for verification of deployments and infrastructure updates prior to release in a way that avoids the potential for impact on the production environment.
Group by application, not by teams
Moving applications between AWS accounts is difficult, with the level of difficulty typically increasing in line with the number of other applications and services your application interacts with.
Given this, consider what would happen in the event of a re-organisation in your company which re-allocates management of applications. This would likely lead to a worst-of-all-worlds scenario, where the complexities of multi-account environments and single account set ups such as highly complex IAM are required.
As such, I would strongly recommend an approach where there are a set of accounts per application. How many accounts depends on your workflow, but at minimum I would suggest one non-production account and one production account per application.
How do I manage it all?
Account creation should be handled via AWS Organizations. AWS provides a tool, AWS Control Tower, which is designed to ease creation and management of accounts. It used to be the case that this tool could only be used for newly created organizations, however it is now possible to apply to organizations and accounts that already exist.
Whether using AWS Control Tower or not, it’s inevitable you will need to write some code to perform actions that are specific to your organization, for example to create and share subnets in a shared VPC configuration.
To provide overall control, you will need to write AWS Service Control Policies. These are like IAM Deny policies that supersede permissions created within an account, so for example you can block anyone, even ‘Administrator’ users, for creating resources outside of the regions you want them to, or prevent use of a specific service.