Benefits of multi-account strategy on AWS

One of major benefits of adopting AWS Cloud in your organization is the ease of creating and destroying resources in your account. Entire production environments consisting of multiple resources can be deployed (e.g. using AWS CDK), tested and destroyed should a need arise.

As the company grows, so do the number of resources it requires. This can be a challenge for the team as it needs to be able to manage and deploy all the resources in a single account. AWS customers want the ability to build, move fast, iterate while maintaining the best security practices.

When multiple teams work with a single AWS account, ownership boundaries become blurred, cost optimization and visibility become a challenge, and the blast radius for potential security incidents becomes ever larger.

As such, a recommended approach by AWS is to set up a multi-account AWS environment. There are number of benefits to this approach, including (but not limited to):

Cost optimization

An AWS account is the default cost allocation unit. As such, having multiple teams working with a single account can make cost optimization challenging (unless you're exceptionally good at managing tags for all resources provisioned in that account).

Having a bill shared by all teams rise by 20% month-by-month can trigger a long investigation into the root cause of the cost issue, which can be a costly process (bear in mind that developer's time is expensive, quite often more costly than the cost of an AWS environment they operate in)

Using multiple accounts (e.g. one account per team) massively improves the visibility of costs caused by each team's activity (if TeamX AWS bill rises by 20% it maaaay be that super large EC2 instance they forgot to shut down).

On the other hand - having greater visibility into the costs of each team can help avoid TeamA spending time on improving the performance of a single Lambda function by 20% (and saving $5.50 per month) when the real problem is a huge TeamB's NAT Gateway bill. In addition to that - having better visibility into their costs can help technical teams make better decisions about their architecture and deployment strategies.

Grouping workloads based business needs and ownership

Developers usually need a development environment to test their code in, a staging environment (to pretend that it's production) and a production environment (to actually deploy the code to the delight of their customers).

While setting up those environments in a single AWS account is possible (although challenging), a better solution is to split those workloads by environment and by team.

Given two teams (TeamX and TeamY) that maintain two separate products (ProductX and ProductY), you may want to consider a following AWS account split:

• ProductXDevAccount (owned by TeamX)
• ProductXStagingAccount (owned by TeamX)
• ProductXProdAccount (owned by TeamX)
• ProductYDevAccount (owned by TeamY)
• ProductYStagingAccount (owned by TeamY)
• ProductYProdAccount (owned by TeamY)

Following this approach allows you to specify necessary guardrails (governance rules for security, operations, and compliance) to each of those accounts.

As an example, while developers should be able to do more or less whatever they want (within limits, obviously) in a development account, they shouldn't be able to casually delete a DynamoDB table in a production account (nor should they have read/write access to its data, depending on data compliance requirements).

Applying security controls per environment

To continue the above example, you may want to apply security controls to each of those accounts. Maintaining different security policies for development/staging/prod environments in a single account is challenging and error-prone (a small mixup of IAM policies can have drastic consequences for your business). Having separate accounts with clearly defined roles (since e.g. development account should never be used for serving production traffic) helps with establishing proper security controls.

Minimising blast radius

Speaking of security, what happens when you do have a security incident? As Dr. Werner Vogels says:

Everything breaks, all the time

Security incidents are never fun, but if they do happen - it's better to have one environment of one service affected than your entire tech stack (if you were to run everything in a single account). AWS accounts are security boundaries provided by AWS, for instance if a development account is compromised, the production database is safe (as it's stored in a completely different account and as such - much, much harder to access by the attacker).

Limits allocation

AWS Service Quotas (a.k.a. limits) are set up on per account basis. Separating workloads into different accounts gives each account a well-defined, individual quota.

As an example, by default you can create up to 100 S3 buckets in an AWS account. With multiple teams working with a single account, this limit can quickly be exceeded and no new buckets can be created (side note: it's possible to raise an account bucket limit to a maximum of 1,000 buckets). Using multiple AWS accounts in your organization can help you mitigate those limitations.

In addition to that, because Service Quotas and request rate limits are allocated for each account, having a multi-account strategy can allow you to e.g. raise AWS Lambda Concurrent Executions limit only in production account (e.g. before Black Friday) while keeping it at the default in development and staging accounts to avoid unnecessary costs.

Promoting innovation and agility

Apart from staging/production environments, you may want to consider deploying creating other types of accounts for developers to use. To quote AWS documentation:

Sandbox accounts are typically disconnected from your enterprise services and do not provide access to your internal data, but offer the greatest freedom for experimentation.

Development accounts typically provide limited access to your enterprise services and development data, but can more readily support day-to-day experimentation with your enterprise approved AWS services, formal development, and early testing work.

If your tech organization is going through a cloud transformation, it's definitely better for engineers to experiment with new services and technologies in their own sandbox accounts (as opposed to your production environment). This way, you can test out new features and see how they work before deploying them to production.

--

If you'd like to learn more about best pracitices for AWS Multi-Account strategy, consult the Organizing Your AWS Environment Using Multiple Accounts whitepaper.