Is one AWS account enough?

What is it like with three AWS accounts? Or one AWS account enough? Is it worth thinking about the separation of resources from the beginning? These are all questions worth thinking about for small, fast projects that are launched in the AWS cloud.

Large enterprise-class organizations are a completely different story because from the very beginning multiple cloud accounts are created, each of which have different purposes.

For example, in one of the projects, where I helped a client create a secure cloud environment (in a highly regulated sector), we already had over 5 AWS accounts, and we had not even launched an application yet.

But let’s leave the topic of large organizations for another day. Today, let’s focus on a simple situation. There is an X application project that needs to be launched in the cloud.
How many AWS accounts are worth creating? Before we get to that, let’s ask another question:

What are the possibilities of an AWS account?

To begin, we need to ask the following question, what options does the AWS account give?

When you want to create an account, you go to the aws.amazon.com website, register, enter your email address, enter all the necessary data, and then, after a while you land in the AWS console.

Following this process, each user receives a single AWS account.

Separation of cloud resources

Everything that will be configured within this AWS account, and everything that will be placed in it (data) is visible only to YOU.

Each AWS account has its own so-called Account ID. For example, your account has an id, e.g. 11111111, and my account has an id 22222222.

Everything that will be configured in the account 11111111 is only visible on it unless intentional sharing of resources with another account has been enabled, e.g. 22222222.

For example, a virtual machine (AMI) image created in one AWS account will be shared with another account.

Limits in the cloud

Every cloud platform imposes limits on users. Both soft limits, i.e. those that can be changed, and rigid or maximum limits that cannot be exceeded.

Limits are imposed on a given cloud account. Depending on the service per account globally or per region but still within one AWS account.

Therefore, we are dealing with limits on resources within the services. For example, the limit of the number of virtual machines that we can run.

Other limits or limitations also exist for API operations within the service. This includes limits related to the possibility of simultaneous same API calls for a given service. For example, if someone once tried to create a dozen AWS Elastic Beanstalk environments in one region at once, would he know what I’m talking about?

Costs in the cloud

Accounting costs for consumed resources. These are also counted for all resources running under a given AWS account.

Quite often this is one of the reasons for dividing resources into accounts to have a quick and clear view of how much it costs, e.g. a development environment looking at the cost of a developer account.

Why is one AWS account NOT ENOUGH?

Working on one AWS account may be risky for several reasons.

First, there is a risk of cloud usage increasing, as more and more individuals and teams will have access to cloud resources.

There is the potential for accidental overwriting of configurations or resources. An unpleasant case may be that someone deletes resources or configurations (e.g. a virtual machine).

In addition, there may be a need to control and separate permissions and access to data resources in the cloud.

Another risk is that one application will consume an excessive amount of resources at the expense of the others.

Quite often, different Business Units have different processes or require different security standards or greater isolation of resources.

There is also the aforementioned issue of the separation of billing/cloud billing. As I previously mentioned, apart from resource tagging mechanisms, another rather interesting element is the division of resources into accounts by cost centre.

Since we already know that working on one account can be risky….

How many AWS accounts should we use?

Recently, during a live session with participants of my cloud course, we just had discussions about how many AWS accounts are needed to start? Assume it is not a very large project, a new application, or the migration of some not very complicated solution.

The first proposal that was made was THREE AWS accounts, but after a long discussion, we came to the conclusion that FOUR accounts are the recommended minimum.

Four AWS accounts to start? Isn’t that an exaggeration?

Let me explain why four is the preferred amount from my perspective.

Account No. 1 – AWS Master Account

When you set up an account in AWS clouds, you provide various data, such as your email address (this is the main login so-called root), and most importantly, a payment card.

We treat this AWS account as the so-called AWS Master Account or AWS Organization Master.

The account, as the name suggests, is only used to manage the organization, we do not run ANY resources on it.

This account is characterized by the fact that:

• It is used to settle costs for consumed resources on all related accounts (so-called Consolidated Billing),
• Additionally aggregates and counts resource consumption in order to apply Volume Discounts,
• Working in this model, it is also possible to share purchased reservations into virtual machines (Reserved Instances),
• Provides configuration of the organization itself (using the AWS Organizations service)
• Provides privilege controls using Service Control Policies (SCPs) that we impose on associated accounts,
• Has configured only those resources that are necessary to manage the organization,
• Access to this account is limited to administrators of the organization only.

Account No. 2 – AWS Logging Account

As part of the platform, there is a service that collects logs related to all activities that happen on each AWS account.

The AWS CloudTrail service provides something like an audit log, thanks to which you can find out:

• who, when and from where logged in to the AWS account,
• who, when launched or changed the configuration of a particular resource or service,
• Etc.

The service itself stores such logs for 90 days, so it is worth creating a safe place (in this case bucket S3), where all these logs will be stored.

It is a good practice to create a dedicated S3 bucket, but it is also good that it is on a separate AWS account.

For this purpose, we set up an account, the so-called Logging Account, which has the only task of securely storing logs from the CloudTrial service, as well as others that require secure storage.

Limited access to this account, plus a properly imposed policy on bucket S3 will allow for secure storage of these logs.

As part of the AWS Organization service, it is possible to “globally” force the CloudTrail service to be configured on each account to automatically postpone logs to this dedicated bucket S3.

Account No. 3, 4? – Application Account

Now we come to the AWS account, where we will configure services and resources for our application.

Here it is worth considering if this one account will be enough? In a situation where we will have several environments of a given application (Dev, Test or PROD).

If proper separation at the infrastructure level (servers, network, etc.) is OK for us, then indeed these THREE accounts are the minimum that is worth setting up for each project.

However, as it turned out during the aforementioned discussion, my good colleague Przemek Malak, convinced me and the other participants that it is also worth separating the environments into different accounts.

This can be especially useful when, for some reason, you don’t want developers to have direct access to the production environment.

Another reason may be the fact that we manage the implementation of applications and infrastructure configurations. While in the development phase, whether the test is a manual or partially automated configuration, the production is already fully automatic.

Finally, it can also be a simple cost separation. If it is important to estimate costs quite easily and answer, for example, the question, “how much did the production environment cost me this month?”

Following this path, we come to the conclusion that FOUR accounts are the minimum that is worth considering for every project.

Summarizing

It’s a good idea to split resources into several AWS accounts.

Doing this, will not only give us more control over who has access to what but also protect ourselves against various types of errors and mistakes, which can sometimes result in large consequences.

Using the same logic as the ideology of AWS Regions (the greater the separation, the smaller the field of attack in case of problems), by dividing resources into accounts, we always reduce the “range” of potential error, unauthorized access or a simple mistake.

The AWS account itself does not cost you anything, whether you have one or five of them, it does not change anything.

Using AWS Organizations to manage your accounts also costs you nothing.

Yes, you are costing side elements, such as CloudTrail, but still, this cost in relation to the benefits is negligible.

Therefore, I sincerely and highly recommend using at least three or even four AWS accounts for everyone, even a small project.

Divide and conquer! Cheers