Welcome to the cloud era, what do you want? … I understand: a test account, 2 pre-production environments and a production account. It will be 30 minutes and you will pay as you go.
We are currently at a point where companies are increasingly opting for the cloud as a place in which to host their solutions and consequently their need to provide a space in which to deploy them is growing. In the case of AWS and when we are talking about different workloads (either by the type of environment or its functionality), this space is represented by the entity “account”. Multiple projects could be hosted in the same account, however, according to one of the best practices of the AWS architecture pillars, security, the ideal is to apply isolation by default, separating the resources of the different workflows.
Let’s start from the fact that we have opted for a multi-account structure, the next thing we have to ask ourselves is: How many accounts? There is really no absolute answer on the number of accounts we should have, but rather a series of recommendations to take into account for a correct sizing. What is certain is that we are going to have to create AWS accounts, configure them and operate them, and all this without losing sight of agility. A fun challenge, isn’t it?
Okay, we already know that we are going to have to provide a lot of accounts and we have to make sure that these accounts are configured correctly and comply with the practices recommended by the WAF, but then we will have to operate them, and of course if managing, for example, the authorization and authentication of one account is already expensive, imagine scaling to 200 accounts; then extrapolate this to other areas of the account, security, networks, audits ….
Are you already overwhelmed, calm down and let’s take it one step at a time, this has a solution.
Many of these services to be configured are susceptible to centralized configuration and operation. This structure of services and accounts is formally called a Landing Zone.
A Landing Zone is an ecosystem of accounts and services that work together as a starting point to securely and scalably deploy multiple workloads and applications with the assurance that they will comply with the design patterns, practices and standards defined specifically for our business. It is important to keep in mind that, although there are a number of guidelines that can guide us on how to design our solutions, there is no holistic answer, as not all use cases are the same, nor all companies have the same requirements. Consequently, creating a Landing Zone is something that involves analyzing the needs of our business and translating them into technical decisions about networks, security, access, etc.
It is true that, regardless of the fact that we have to perform an analysis to ensure that this ecosystem can meet the needs of our use cases, Landing Zones usually have a similar structure in terms of accounts and services they provide. They usually have the following architecture.
As we can see in the diagram, the ecosystem is composed of different accounts, called core or foundational accounts, what are they for?
This is the master account, from where, using AWS Organizations, we will create, organize and apply service control policies to the rest of the accounts. Using AWS Organizations also gives us the possibility to identify and manage the costs of the accounts belonging to this ecosystem based on the classification we make, using OUs. Another of the functionalities offered from this account is the centralized management of authentication and authorization using AWS SSO.
The shared services account is intended to host those centralized services and applications that the data and engineering teams consume for the operation of your product. For example, messaging services, global databases, cross-cutting continuous integration services, etc.
Associated Services: AWS AD, C.I./C.D.
The purpose of the audit account is to store in a secure, centralized and isolated way the logs created by the different ecosystem services.
The security account will be responsible for hosting the services to centrally manage, audit and operate the security of the product accounts. In addition, it is also the account responsible for hosting the roles used to perform security and auditing operations. These roles, called “breaking-glass”, will be used in case of emergency to act in the event of an incident.
The purpose of this account is to serve as a single point of operation for cross connectivity services that, depending on our company’s needs and policies, will handle everything from DNS resolution to centralizing the operation and monitoring of east/west and north/south traffic.
By using this ecosystem and correctly configuring the associated services, we can guarantee that the accounts created under this organization have the aforementioned functionalities as a base. Is this enough?
As you may remember before I emphasized the fact that there is no holistic solution and that we will have to design based on the needs of our business and usually this also involves making other specific configurations that go beyond those already centralized by AWS. At this point it is important to define these configurations and implement them as a base in all those accounts that we create, a topic that we will cover in the next chapter!
Strictly Necessary Cookies
Strictly Necessary Cookie should be enabled at all times so that we can save your preferences for cookie settings.
If you disable this cookie, we will not be able to save your preferences. This means that every time you visit this website you will need to enable or disable cookies again.
3rd Party Cookies
This website uses Google Analytics to collect anonymous information such as the number of visitors to the site, and the most popular pages.
Keeping this cookie enabled helps us to improve our website.
Please enable Strictly Necessary Cookies first so that we can save your preferences!