Getting off to a good start in the AWS cloud

To implement a sustainable solution to provide services in different geographies and/or customer typologies, or even for a diversity of projects, we usually propose the progressive implementation of a Landing Zone through the Control Tower service.

(SPANISH) Como comenzar con buen pie en la nube de AWS

The AWS Control Tower service deploys a landing zone with 3 accounts in a single organization: Root, Audit and Log Archive, and provides a Service Catalog shared between all accounts with a procedure to create new accounts within the organization in a semi-automatic way. For its functioning and operation, Control Tower proposes a hierarchical system in which the accounts are structured as follows:

This service relies on AWS Organizations and AWS SSO to deploy a hierarchical pattern of accounts in a centralized, but above all scalable and maintainable way. The service also proposes ways to unify account management with AWS IAM in the form of delegated roles and enforcement of AWS-owned or AWS-proposed policies across all derived accounts, significantly increasing security through passive mechanisms, account isolation and ephemeral yet centralized permissions.

This hierarchy creates by default two additional accounts for auditing and tracing the use of transversal services (log), on the other hand, our proposal is to complete it with a shared account for all those processes and transversal elements e.g. VPN, SCM, etc. ….. In this model, the root account only has the billing, Organization and SSO management and support (we recommend hiring at least business level), all other actions are performed in the child accounts, always depending on their level of specificity or scope.

Finally, the least developed part of Control Tower is the automation of the management of the Control Tower itself, however, much of the work is done only once in the initial stages of deployment. In case it is necessary to extend the behaviors of creating new accounts, it is possible through AWS proprietary tools such as Cloudformation and Lambda.

What challenges or points should be taken into account when implementing a Landing Zone with Control Tower?

• Integrations with LDAP and/or ADFS. This part involves disassembling the default SSO and it is necessary to validate that it has SSO support and can involve quite a lot of integration work.
• The payment system must be well configured, a card in the customer’s name if the amount is relatively low, and if not a bank account, but this can only be done after the first payment (not from minute 0).
• For security reasons It is preferable that nothing has been done on the root account.
• Adding an account that already exists is quite complex because it does not usually recognize the guardrail and UO of organizations.
• It is interesting if you have in mind some restriction that can be converted into additional security policies that you want to implement.

What customizations have I discovered that may be helpful?

1. Set spending alarms agreed with the customer. In thresholds of 25% incremental with respect to what he estimates as acceptable monthly consumption.
2. I usually create a shared account to start with, where I host things transversal to several accounts, e.g. CI/CD, SCM,…
3. I also usually create a networking account to facilitate the creation of Transit Gateways or VPNs in the case of hybrid cloud infrastructures.
4. On the other hand, I usually remove the default groups and create a super-admin group (access to the root and audit accounts), another DevOps Cross group to the environment/project accounts and a particular group for each project/line of work.
5. To contract in the Root account business support that enables urgent tickets and technical tickets.
6. Enable the IAM permission for billing in the Root account so that the administrators of the child accounts can see the spending of their account.
7. I enable some additional GuardRail controls, especially those related to not leaving orphaned disks and others that generate unnecessary spending.
8. I generate a mail group and get the Root users with their MFA from each and every child account, in case there are any security/access issues. A useful tool for this are the topics:

• project-x-group@keepler.io => root
• project-x-group+log@keepler.io => log
• project-x-group+audit@keepler.io => audit

How long does it take to set it up and configure it?

It is operational in a couple of hours, I would say that to make it fully operational, between creating users, groups, etc,… it takes 1 or 2 days of work. It is not a very demanding task, in general it is a matter of guided assistants that do almost all the work.

Originally published at https://keepler.io on September 15, 2021.

🎭 Subscribe to read without limitations
📚 Read other related material
⭐ See my recomendations
📨 sign up to my list