This article was originally published as a blogpost at FAIR CG’s website.
Introduction
Any development environment needs segregation in terms of responsibility, cost, security, and manageability. However, most organisations start building on AWS oblivious to this problem. A single account is maybe even desirable to beginners because everything is in one place, making operations seem very convenient. But realisation soon strikes that one account does not provide the level of isolation needed to function efficiently. Problems grow with the number of projects.
Ideally, development, staging and production environments should be set up separately. In a single account setup, lack of segregation can lead to unwanted overlapping of certain services. It is not difficult to imagine a scenario where two teams working on entirely different products accidently eliminate each other’s resources.
It is not just related to the teams stepping on each other; developers need to experiment, create proof of concepts and maybe just play around with services. Security and access management also become prime concerns and a number of questions arise such as:
- Who has access to what?
- Are different security baselines being implemented correctly for each project?
- What if client X wants isolated access to their solution due to an internal audit?
A natural solution to these problems is a multi-account setup, which is something that is widely known. There are companies that have hundreds of operational accounts for various purposes, which is why AWS introduced AWS Organizations that enable companies to organise their multi-account setups. AWS Organizations groups multiple accounts into logical units called Organizational Units (OUs), which can then be managed on a holistic level, enabling features such as consolidated billing and attachment of different policies for various security and compliance needs.
It might seem that AWS Organizations can solve all these problems but there is more to this picture. In AWS Organizations, the setup is entirely manual and this is time consuming. It can be imagined that provisioning a new account, setting up all necessary security constraints and meeting certain compliance measures will involve a lot of organisational machinery, which needs time. This is a disadvantage for agile teams, preferring to build things fast but are not able to provide developers with the sandbox environment they have requested in less than two weeks after passing all compliance and security checks.
AWS Control Tower tries to solve those problems. It provides a managed service that is responsible for centralising access to all the accounts, creating logical units of accounts, aka OUs. They enable segregation by enforcing certain rules (guardrails) across OUs to provide compliance with certain security and access rules, and help organisations with creating new accounts quickly.
What is the AWS Control Tower?
AWS Control Tower is a managed service on top of other managed services provided by AWS that creates a pre-built multi account framework by primarily using AWS Organizations, AWS Service Catalog, AWS Single Sign-On and AWS Config. It enables organisations to build, move fast and stay secure.
A multi-account environment in AWS may be set up manually by wiring up AWS’ services together or automatically by using AWS Control Tower. Once an organisation has its multi-account setup ready and configured, it is referred to as a landing zone.
A Key Concept: Landing Zone
The term landing zone should not be confused with AWS Landing Zone, a service launched in 2017 (now part of AWS’ long-term support). This differentiation is important because users often get confused when they come across the term in different contexts. In his re:Inforce (2019) talk, Sam Elmalak differentiates them by pointing out that one of them is capitalised and the other one is not.
A landing zone, as per the official AWS documentation, is a “well-architected, multi-account AWS environment that is based on security and compliance best practices.” It is a cloud environment that offers a recommended starting point, including default accounts, account structure, network and security layouts, and so forth. From a landing zone, you can deploy workloads that utilise all of your solutions and applications. It gives a holistic picture of how the entire AWS setup of an organisation looks like.
The automatic creation of a landing zone and its management is one of the primary concerns of AWS Control Tower.
Let’s visualise what has been said about AWS Control Tower as a service and the features that it offers in the diagram below.
High Level Overview of AWS Control Tower
Logical Grouping of Accounts and Consolidated Billing
At a basic level, there has to be a mechanism where accounts can be managed and this is something that AWS Control Tower is primarily concerned with. The wheel, however, is not being reinvented here in any way. AWS Organizations is a service that is used by AWS Control Tower for the creation and maintenance of these accounts. AWS Control Tower creates two OUs by default: Core and Custom.
The Core OU contains two default accounts, one for logging called the Log Archive account and one for audit called the Audit account. The purpose of these accounts is to provide segregation for logging and auditing because such activities should always be isolated from day-to-day operations.
The Custom OU is meant to contain custom/shared/sandbox/SDLC accounts that an organisation will need for its operations. This OU is empty by default.
All of the mentioned accounts and OUs can be managed and tailored accordingly from the dashboard of AWS Organizations.
Consolidated billing, provided by AWS Organizations, enables organisations to have better visibility and tracking of expenditure costs in a single bill.
Access Management
Centralised access management is critical for any large to medium scale organisation and AWS Control Tower answers this by setting up an AWS SSO directory right from the start. Organisations that have their own identity server can integrate it with AWS Single Sign-On to have better control and management of who can access what and when. This can be ideal for certain situations, such as employee offboarding, disabling just one identity can revoke all the granted access.
Guardrails
Guardrails are preconfigured rules for security, compliance and operations. There are certain security, networking and general baselines that an organisation wants to preconfigure in every account they provision. For instance, an organisation might have a policy that its EC2 service remains unavailable to developers by default and hence wants to have a preconfigured constraint that disables access to EC2 for their sandbox OU.
Another example of this could be a client that is concerned about their application code and assets and does not want the team to have development access outside from the office premise. This is where guardrails come into play.
Guardrails can be divided in two categories: preventive and detective.
Preventive guardrails ensure that accounts maintain compliance. To exemplify this, a preventive guardrail can stop a developer from turning off logging via CloudWatch on their sandbox account. AWS Organizations introduced a way to configure preventive guardrails by providing Service Control Policies (SCPs), which are rules that can be applied to an OU or even a single account. One can think of an SCP as an IAM policy but it should be noted that an SCP has higher precedence.
Detective guardrails, as the name suggests, detect and inform administrators about certain behaviours and use patterns. For instance, a detective guardrail can alert the administrator in case anyone has logged in to the primary logging account. Detective guardrails are implemented using AWS Config and Lambda functions and compliance or non-compliance to certain rules is shown to the administrators via a dashboard.
AWS Control Tower goes a step further and pre-configures a list of necessary guardrails that are required by an organisation. AWS categorises their Guardrails recommendation into two groups: strongly recommended and elective.
Account Vending Machine
It is essential for an organisation to be able to provision accounts efficiently and AWS Control Tower makes life a little easier by setting up a simple interface for account creation using AWS Service Catalog and AWS CloudFormation. Since everything is set up by AWS Control Tower, account provisioning becomes as simple as entering basic information of the user, selecting an OU and hitting a button.
AWS Service Catalog, a service that enables organisations to set up portfolios or catalogs for approved services, provides the interface to create new accounts and Stacks, along with StackSets, in CloudFormation are used to define the structure and the services that are required in the account.
Service Catalog and CloudFormation provides the required flexibility and control and enables organisations to tailor their account provisioning for various OUs.
The following diagram illustrates all concepts discussed above.
Conclusion
This article explains the foundations of AWS Control Tower, touches on the functionalities of the supporting services and introduces a minimal baseline for a landing zone. There is still so much that can be written about AWS Control Tower due to its sheer complexity, the number of services it offers and the ways those services can be tweaked. It is difficult to find a single source that goes through all the concepts and therefore a learner has to rely on multiple sources.
Here is a talk that helped me to conceptualise AWS Control Tower and a hands-on tutorial that you can check out until the next part of this blog series is published that will explore best practices for designing and setting up a landing zone for organisations. Dig deep and have fun!
