Niezbędnik – Zarządzanie Kontami AWS w KAŻDEJ Firmie

Necessary — Management of AWS Accounts in EACH Company

Ponad 14 lat w branży IT. Konsultant i architekt projektów Amazon Web Services. Entuzjasta rozwiązań serverless. Współtwórca AWS User Group (3500+ osób). AWS Community HERO. Masz pytanie, napisz do mnie.
pl flag
en flag
Voiced by Amazon Polly

The adventure with the public cloud is easy to start — this is one of its many good qualities. “Entry threshold” is not too high — in a few minutes you create an account for example in AWS, start your first virtual machine or any other service very quickly.

What's important — you don't have to be a member of a huge organization to start using the cloud. You don't even have to work in any company — you are the master of yourself, at any time each of us can become a conqueror of Cloud Computing. Many have already done so — and you? :)

Today, however, we will look at a very important topic: managing AWS accounts in the company: large, medium, small — EVERY.

The beginning of this story is simple ? It starts with a visit by the Chief, who smiles on his lips declares that Project X is supposed to work in the AWS cloud. But you're ready for any challenge — you have a private, cloud-based profile, first training behind you, and maybe you've already committed the first projects in the “grey zone” category. Within a few moments, you will set up the required corporate account with AWS.

The next steps also look like a fairy tale — you design the architecture of the application, then it goes to the developers, and then you're part of the company's success. Hula application as it should! But as it happens in life — appetite grows as food and new needs arise. It's time for the next web application, queue the need to move the dev/test environments and connect everything to the local data center.

And the staircase starts — you need to create the assumptions of multi-environment architecture, think about the division of accounts, consider accounting issues, and much more.

So keep reading carefully, as soon as I'm going to tell you how to arrange the most important elements of this very interesting, cloud-based puzzle. Get to work!

Account Structure — Adult Puzzles

The structure of accounts in each company will always be different, individual entities have their own characteristics of operation. Systems and applications differ from each other, we also approach data exchange, cost accounting, security and regulation etc.

This does not change the fact that when thinking about the structure of accounts, it is necessary to take into account:

Financial issues:

Who pays, how the use of resources will be billed, who is responsible for costs and their amount.

How you can reduce and optimize fees: purchase resource reservations, volume discounts.

Do not invent a wheel, use dedicated tools like Trusted Advisor.

Limits and capabilities of the cloud-based platform:

The upper and lower thresholds are waiting for you in the capabilities of AWS services.

Please note the limitations related to the amount of resources you can run per account/region. Include “soft” limits that you can change and physical limits that you will not be able to control.

Security and access to information:

That is, strategic important (as always) — access management for users and other resources.

Think well about the flow of data between systems and the limitations associated with it.

An example, model account structure is shown below.

Central accounts perform roles called service, i.e. aggregate and settle costs. They also have the task of collecting, protecting and analyzing logs from other accounts and systems running in them. Other purposes include providing shared services such as a dedicated connection to the local data center.

The role of other accounts (Use case-based accounts) is already to provide “real” services. These accounts implement applications and run specific AWS services. These accounts are usually divided into applications, types of environments, or even business units.

However, from the cost point we still have one Billing account, responsible for billing and paying AWS services. The remaining accounts are only connected to it, which nicely demonstrates the picture below.

Network Architecture — Reproduce Virtual Private Clouds

Another significant element of organizing and managing accounts is the network architecture. Each account must configure network segments (the so-called Virtual Private Cloud (VPC), which may have different architectures depending on the account type.

Here are examples of the characteristics of VPC elements:

Some include services for internal use,

Others present resources for the Internet (web applications),

Some of them must communicate with each other (via e.g. VPC Peering),

Additionally, some connect to resources in the local DC (via VPN, dedicated connection).

After taking into account VPC, our example account topology gained additional valuable elements.

As you can see above, the shared services account provides a connection to the local DC. What's more, it shares connection with other accounts where applications require, for example, access to data in DC or other services such as Active Directory.

Security, Ah It's Security

Now we will touch on a very important and sensitive aspect of AWS account structure — security. In this area it will not be possible to present only a valid pattern, since a large part of the configuration will be (as always) individual, which is influenced by the services running on the account.

Good news — on each account, you can highlight a base configuration that is common to all. To such settings include:

Access control, password policy, permissions for administrators.

Protection of root account, MFA, etc.

Log collection configuration: CloudTrail, Flog Logs.

Configuration management and changes made: AWS Config.

These settings control basic security issues, including protecting and blocking the use of a root account for daily work. Separating a dedicated account for collecting and analyzing logs will help you to ensure that logs are not only collected, but also protected from deliberate or inadvertent deletion.

The introduction of the above-mentioned configuration elements is an implementation of the basic security set. All logs from each account are aggregated on a single central account, to which only designated persons should have access.

Access Control — What For Who?

It is pleased that each account has its own IAM configuration — a directory of users, groups, permissions and roles. Some of these settings will be shared, such as administrative or operational access. However, the other configuration options will depend on the type of account. Developers should be entitled to development environments, but not production environments. Only the security department will have access to the log account.

Let's also not forget about Active Directory or other authentication mechanisms — some of the accounts will require access to them.

Head up! You have plenty of options to help manage your accounts and access control:

Cross-account roles — allowing users to grant permissions from one account to resources and services in another account (IAM)

Federated Access — integration with external services (so-called Identity Providers) using e.g. SAML.

Here is the topology enriched with additional elements, serving in this case the broadly understood protection.

The shared services account manages user accounts and groups, or integrates with external Identity Providers. Access to other AWS accounts is managed using IAM Role.

Lucky — There are Additional Tools, There is Automation

I know, so far, we've only multiplied more options, increasing the difficulty of controlling all the elements. In the next step, I will help you gain more control over this process and, above all, simplify it considerably. The key passwords will therefore be: consistent configuration for all accounts and automation of repetitive tasks.

AWS CloudFormation — template strength

This is a very useful solution, which, through pre-prepared templates, allows you to implement the configuration in the form of so-called stacks. For each account, the same previously approved template is used, which gives great confidence that the configuration is consistent. The accepted process of verification, control and acceptance passes not only the basic form of the template but also all changes, which gives you complete control over its life cycle.

AWS CloudFormation StackSets — Towards more automation

This option appeared relatively recently enriching the previously discussed Cloud Formation service. It allows you to implement a whole group of stacks on multiple accounts or groups of accounts organized in Organization Unity (but about that in a moment).

In this case, an additional administrative account appears in the structure of our accounts, whose role is to implement the settings globally.

For example, the company policy says “we do not use a root account to work with AWS”. Additionally, the security department wants to make sure that no one is logging in to this account. So you can create a CloudFormation template that will implement the desired login monitoring on the root user. Doing it in one account is not a problem, you will click it quickly. However, when there are several accounts, it will take a long time to click each in turn. And then the StackSets option will work great, remember it necessarily!

AWS Organizations

Bravo! You have reached the point where you can control the configuration of multiple accounts. But how will you be able to simplify the very process of creating the necessary accounts and their initial configuration?

I have something for you — it's AWS Organizations, which is a dedicated service for managing AWS accounts and grouping them into the so-called Organization Unit (OU). As part of account management, you can:

Create new accounts,

Add existing accounts,

Delete accounts from the organization,

Liquide/close accounts.

Additionally, on accounts grouped in OU:

You impose Service Control Policies — this is the control which services and actions users can perform on a given account.

Implement CloudFormation templates — thanks to integration with the previously discussed CloudFormation StackSets.


The solutions described by me are implemented very often in large companies. But this does not mean that they can not use them also the smaller ones.

I have a conviction that even if your company takes its first steps in the cloud, next few minutes will start growing like mushrooms after the rain. From the outset, it is worthwhile to think about their hierarchies, roles and management methods in relation to the aspects described earlier. This gives you easier control over your target cloud environment, regardless of its scale.

In Chmurowisko, we use AWS Organizations and CloudFormations from the very beginning because we see that they greatly facilitate management at a small scale.

There will also be cases of more demanding companies, where the solutions described above do not satisfy all the needs — especially non-standard ones. But there's nothing to worry about — the AWS platform integrates easily with other tools and allows you to create custom integrations. In a simple way, you will be able to enrich your environment with additional possibilities, handling unconventional situations is possible.

In conclusion, regardless of the scale of the company, it is really worth taking care of good and thoughtful account management from the outset. A little more work at the beginning is a lot less on the head in the further stages.

And remember — the cloud will not speed up and improve your work. It gives you the tools and opportunities with which you can achieve this. Cheers! Cheers! ?