Segregate resources and good hygiene between AWS accounts

Each resource you create on AWS is associate with an account, but you are better off with one account for project.

Having different AWS Account allow a much simpler segregation of resources and billing.

Accounting

For an accounting perspective, billing segregation helps in allocating costs to the correct project.

The account associated with the project FooBar will get a different bill than the account associated with the project FuzQuo.

If the project FooBar is managed or paid by the R&D group of the company, it is much easier to associate this cost to R&D. If FuzQuo is a new project to improve efficiency in the accounting department, its cost can be immediately associate with the accounting department. You will just get different bills.

Engineering

From an engineering perspective, having different account allows to not mix up resources. From the account FuzQuo you simply won’t have visibility over the EC2 instances running in the account FooBar. You will not know how many AWS Lambdas are invoked, nor which S3 bucket is used or what DynamoDB table is read.

This does not mean that it is not possible for different account to communicate, but it must be an explicit choice with a well-defined API (hopefully).

Another advantage is about managing complexity. AWS accounts can become quite busy with different resources in different regions. If each AWS account has only resources needed for a specific project, it doesn’t get overcrowded with difficult to navigate interface and engineers wasting hours looking for a specific EC2 instance or S3 bucket. Moreover, changes of mistakes are very much reduced. Less resources to manage, more context for the smaller number of engineers actually working on a specific account with only the needed resources.

Compliance

From a compliance perspective, different account segregate not only resources but also data.

It will be necessary to audit only APIs that exposes data as external endpoint. It will be simply impossible, with default configuration, to have resources in an account access directly data into another account.

It is possible to explicitly allow access of data and resources between accounts, but this will require explicit effort.

Limits and performances

AWS has limits in place for pretty much any action you could take on an account.

There are limits on the amount of EC2 instance you can create, on the Lambda invocation you can do in one hour and the amount of S3 bucket you can have.

Those limits are quite high and usually are not hit for small and medium projects, however several projects all concentrated in a single account can very well hit the limit of S3 buckets. Or of EC2 instances.

If each project has its own account, the limits are checked for a subset of resources that the whole organization needs. Making it much more difficult to hit the limits.

It is also quite odd to have two heads of department going back and forth about AWS limits and which department should start using less S3 buckets.

Security

AWS accounts are segregates between each other.

If a malicious actor gets access to one account, it cannot damage the other accounts and overall the blast radius will be limited. Still serious, but limited.

Practically speaking, most organization don’t need to worry about malicious actors. It is enough to follow best practices and not get paranoid.

But the same reason applies to honest mistake by engineers or interns. With different accounts for projects, the damage done by a simple mistake is limited.

Why not

While we have clearly outlined the benefits of segregating AWS resource, there are also some costs.

An increase in complexity. Each account will be LESS complex overall, but there will be more accounts in a standard organization. With people accessing maybe 4 to 5 different account in a workday.

Velocity. Having a single AWS account, especially at the beginning is marginally faster. You can go a pretty long way with engineers not touching the resources they are not 100% sure about and using tags.

Beside those valid reasons, my suggestion would still be to segregate resources by projects using accounts.

Not segregating resources tends to get sticker and difficult, I am familiar with big, quoted, corporation still entangled with a single AWS production account. This creates a cascade of complexity that is very difficult to disentangles with long term, years long projects for small progress.

Create a new account

The benefits of creating multiple accounts are clear.

Indeed, there is an API to create them, and it can be done over the AWS CLI with the organizations create-account command:

aws organizations create-account —account-name $account_name —email $account_email

But it can also be done using the console over this link.

The email account should be a service account that stay in the organization, not a personal email.

Ideally for each project a new email could be created and associate it indefinitely with that account and that account only.