When to Consider Multiple AWS Accounts

So recently I was asked when an organization should consider using multiple accounts within AWS, and I wanted to give a synthesis of what I evaluated when answering this and what factors came into play. This should be as easy as do the benefits outweigh the negatives that come along with this approach for your company or where you believe your company is headed. Here's a quick breakdown of what you might gain or lose with your AWS account strategy:

Multi Account Pros:

1. Multiple accounts make it really easy to break down usage between different service areas or applications within your organization. Period. End of thought. End of Paragraph. No tags or parsing needed.
2. You can set budgets and service limits on a per account basis. If you want a simple method to give your Development team a budget or a limit on the number of assets that they are able to provision, create an account for them and send them on their way.
3. This reduces the blast radius for human error. If you accidentally destroy an auto scaling group (ASG) a little too quickly, you can rest assured you did not run that command on production.
4. Encourages good Separation of Concerns for your organization. Developers should be focused on what is needed to get their sprint/feature/train moving forward. They should be less concerned about the firewall rules and maintenance windows when artifacts can be moved. It also sets you up well for looking at an effective Deployment Pipeline if your company is not there today.
5. This encourages Infrastructure as Code or IAC practices. If you're regularly build environments to get your application running when you release to prod you will have an significant motivation for effective and documented deployment process. More reps = consistent results.
6. It encourages teams to have ownership of their output, and empowerment to deliver.
7. Two Accounts != (Does not Equal) twice the permissioning work. Setting a simple role up for your administrators is a ten minute activity and gives you a great audit trail of who is doing what.

Multi Account Cons:

1. Transferring data for your application can either be expensive(data egress can be a non-inconsequential component of your bill) or complicated if you're seeking to poke holes in Production environment to get data (beit Shared VPC's or private links).
2. If you have a distributor you may have restrictions of how you can adopt an Organization approach.
3. There will be more IAM, roles and users to watch and maintain. Fortunately there are tools for that.
4. This increases your security surface area. If you are using PII or sensitive data inside your development environment or staging you have more things to protect and watch. Potentially not your CISO's favorite approach.
5. Greater possibility for runaway costs. Provisioning an EBS volume with one too many zeros of IOPS is a hard thing to spot when you only have one account.
6. If you are a multi cloud provider shop, or could be in the future, it will be painful to manage and operate many accounts for each of the provider. Keep it simple unless you can keep your teams dedicated to their specific platform. Also don't be multi-cloud if you can avoid it.

Questions that you should consider:

Here's a quick breakdown of questions to answer:

Question	Direction you should be leaning
1. How many administrators do you have within this environment?	The lower the number, the lower the number of accounts you should be aiming for.
2. Is development a part of your core competency?	If your are working with commercial-off-the-shelf utilities and providing services, aim to keep your environment simple as possible
3. Do you have a means of controlling your spend in your cloud environments?	Multiple accounts can give you very straightforward billing information if you do not have a strong approach to this.
4. Do you have a dedicated security team or one that is independent of your operational team?	If not, keep it simple.
5. How many applications is your environment going to support in two years?	Switching costs are expensive, but don't build for a future that is too far out.

A solution for most companies

So I don't have a silver bullet for your organization, but here's what I recommend to my clients:

Customer A:

Customer A is not a technology company, they are looking to run a few of their applications and stay as focused on their business as possible. They outsource all of their IT services and are planning to do so as long as possible.

Keeping this simple served this customer the best. A single account; a straight forward network. While from the start they didn't have anything to deploy into the secondary subnets, they were ready if they needed to move their images. This could be handed to any service provider, and they would not require significant onboarding to operate the infrastructure as designed.

Customer B:

Customer B has an internal IT practice and an application that they develop inhouse, but is not central to their value proposition. They may be increasing their development into a few additional projects in the near future (1-3 years).

The Organization Account, serves to consolidate permissions, logs, and billing information from all the child accounts. This provides things like:

1. Preservation of audit logs within development environments
2. Consolidated billing and line items for Production and each development effort.
3. We can quickly set up permissions for production and give developers the direct access to services they'll want to develop with.
4. Development environments will be identical to production environments.

Customer C:

Customer C is an enterprise software company where the operation of their product must be not only their core competency but a differentiator in the market. They have multiple IT organizations within their company and shared services that interoperate.

I would argue that the above architecture could still serve quite well even with these additional requirements. However we often see the addition of:

1. Multiple production environments with Shared VPCs or Peered VPCs.
2. Shared Services environments that must provide services to nearly all resources.
3. A dedicated security account for log/audit aggregation.

Fight complexity unless there is a compelling and direct reason to acquiesce. Be practical with your team and where your team will be in a few years. Don't build out staging environments if your development practices don't have automated testing.