An AWS account does not have any cost by itself, so why we should share the same account across different scopes ?

Here we’ll talk about how we think real environments should look like and how we’ll do it in ARGLabs, since it’s just a lab and not a real environment.

Read more: AWS multi-account model and ARGLabs

AWS recommends the multi-account model for many reasons, we’ll focus on just a few of them here.

Access control

An AWS account is the first access control layer and blast radius limiting mechanism.

AWS accounts costs nothing by themselves, so you may have 3 or 56 accounts that you will only pay for what you run inside them.

It is much easier to control which accounts users have access to than to control the different access that different users need to different resources within a unique account.

So, access control is the first reason to do that.

Cost

Not only AWS accounts add no cost to your organization but it, in fact, helps to reduce costs.

In a shared account with multiple teams, applications and/or products, how do you know what are the costs for each of them ? Ok you can use tags, but there are many things that are not easy like this.

When you define a scope for AWS accounts and limit it’s usage to that scope, you can easily know the costs of that scope. Say you define a large product as an scope, and you run the entire product on one account and use another one for development/QA environments. The total cost of this product is the simple sum of the 2 accounts billings.

Isolation

Having just one scope inside an AWS account brings ownership to the people involved.

The responsible people is more likely to care about costs, efficiency, security etc because they will be the ones that the finops, security and other teams will talk to in case of problems. They own their product and the AWS account is like their exclusive environment where their product runs on.

The fact that only they are using the AWS account will make them confidently to take decisions like completely purge the development environment when they are not using, reducing costs to literally zero (yes, destroying all the infrastructure also!).

AWS account scope

What is the AWS account for ?

Should we have one set of accounts (environment accounts) by team ? Or by product ?

There’s no one-size-fits-all answer.

You should decide it based on the above benefits. If you have a large product made by a few teams applications and makes sense to have this product costs clearly visible and you don’t need to have different permissions for the teams that will have access to it, go for it.

If you have many apps from a group of teams that are part of a “business unit”, use accounts for that business unit.

You decide it.

In ARGLabs

Here in ARGLabs we’ll be using just one scope for our examples because it’s a lab.

One scope for all, that’s why we named it “The AIO (all-in-one) Scope”, and we’ll have 3 accounts for the different environments.