AWS Account Strategy

Brett Gillett

There are quite a few decisions you need to make when you’re first getting started on the Amazon Web Services (AWS) platform. One of those decisions that are often overlooked in the thrill of getting started is AWS Account Strategy.

There are two options when it comes to deciding on an AWS Account Strategy: - A single AWS account - Multiple AWS accounts

In this article, I’ll outline both options and why I almost exclusively use a Multi-Account strategy over the single AWS account option.

Single Account Strategy

A Single account strategy is what I see the majority of customers use. It’s pretty self-explanatory - all your AWS resources regardless of environment, department and project are housed in a single AWS account.

Seems simple enough right? Sure, it’ll get you started fast, but some issues will come up over time.

Here are just a couple of examples of issues I see organizations struggle with when it comes to managing a single AWS account.


If all your resources and services are contained within a single account deciphering, who is responsible for which portion of the AWS monthly bill becomes difficult quickly.

Tagging will get you only so far - you are tagging, right?

But there are things like AWS Support and Data transfer which you cannot tag - how are you going to allocate those costs?

Identity and Access Management (IAM) complexity

Since you’re practicing least privilege in your AWS account you probably already have some IAM Policies and Roles in place - right? Well managing Policies and Roles to keep one department (or project) from modifying (or deleting) another projects resources will possible becomes very complex very quickly.

Workload Isolation

When using a single account strategy how can you 100% guarantee that issues with resources deployed for one project (or environment - development vs. production) won’t affect another team’s resources? If you need to guarantee separation, then a single account strategy is not going to work.

Multi-Account Strategy

Here’s the strategy I wish more organizations new to AWS would adopt from day one. While running multiple AWS accounts increasing the complexities associated with account management it alleviates other complications as we mentioned in the previous section.

Chargebacks are no longer an issue. Each account could correspond to an individual department or project team who is using AWS - you no longer need to worry about allocating support costs or data transfer. Since each team has their account allocating costs is straightforward. At the end of the month, you merely bill the team for their account consumption - super easy.

Having separate accounts is also a fantastic method of Cost Optimization. If a team has to pay for their actual consumption, they are more likely to be more careful about what they do in the account.

How about IAM complexity? Because we’re practicing least privilege in all of our accounts, it’s still there but to a much lower extent. We can quite often reduce the Conditions and additional layers of protection when we have separate accounts.

Finally, workload isolation. Since every team now has its AWS account, we can 100% guarantee that one project (or team) cannot directly affect another by making changes on a Friday afternoon.

Proposed Account Structure

Without getting into too many details here is the basic strategy I recommend to all my clients - regardless of size.

At a minimum, you create two AWS accounts, in all likelihood, you’ll need more, but this is the bare minimum.

Here are my suggestions for AWS accounts to start with:

  • Payer (or Master) account: This is a billing-only account. No AWS services are deployed here. All of your consumption rolls up into this single account. One bill at the end of the month - super easy.
  • Project (or department) account: This account created from the Master account is where your AWS resources will be deployed. That’s it.
  • Security account: We could spend quite a bit of time on the security account. For now, we’ll just say it’s where all the logs (AWS and otherwise) will be stored.

If you want to setup an account structure that will be flexible and grow as your AWS usage does have a look at the diagram below - it’ll give you some ideas on the possible.

AWS Account Strategy

AWS Organizations

At the beginning of this section, I mentioned the increased account management complexity that comes with a multi-account strategy. One way to help alleviate some of this complexity is to leverage AWS organizations. This service allows you to centrally manage AWS accounts by creating logical groups with Organization Units and policies. Make sure you use it from day one!

Wrap Up

I hope by now it’s clear which option I recommend to all of my customers - even the tiny customers who are running a simple website or application on the platform. Spend some time before deploying and plan out your account structure - it’ll save you plenty of headaches later on - trust me.

Brett Gillett


Like what you read? Why not subscribe to the weekly Orbit newsletter and get content before everyone else?