AWS Control Tower - An Introduction

Hello Folks, as a continuation of our AWS SAA series, we will discuss briefly about Cloud Tower. Lets start.

AWS Control Tower offers a straightforward way to set up and govern an AWS multi-account environment, following prescriptive best practices. It is the evolution of AWS Organizations.

It orchestrates the capabilities of several other AWS services, including AWS Organizations, AWS Service Catalog, and AWS IAM Identity Center (successor to AWS Single Sign-On), to build a landing zone in less than an hour. Resources are set up and managed on your behalf. To help keep your organizations and accounts from drift, which is divergence from best practices, AWS Control Tower applies preventive and detective controls (guardrails). For example, you can use guardrails to help ensure that security logs and necessary cross-account access permissions are created, and not altered.

Parts of the Control Tower

Landing zone – A multi-account environment.

SSO/ID Federation, Centralized Logging and Auditing using a combination of services like CloudWatch, CloudTrail, AWS Config, SNS etc...

Guard rails (controls) – designed to Detect/mandate rules/standards across all accounts

Account Factory – A template which Automates and Standardises new account creation

Dashboard – single page overview of the entire organization

AWS Control Tower is created out of a standard account. This account becomes the management account of the landing zone. It contains Control Tower – which orchestrates everything

AWS Org – provides the multi-account structure like OUs and SCPs

SSO now known as IAM Identity Center - means we can use AWS internal identities or external federated IDs to access everything in the LZ that we have permissions to.

When it is setup the first time, it creates two OUs

1. A foundational OU – named security OU

2. A custom OU – named sandbox – used for less testing and less rigid security situations

In the foundational OUs two accounts namely Audit acct and Log Archive account are created

Log archive account

This is for users who need access to all logging information for all of the enrolled accounts in the landing zone.

E.g – AWS Config Logs, Cloudtrail logs

These logs are stored in this account so that they’re isolated. Need to explicitly grant access to this account Read only archive account for logging

Audit account

It is for users who needs access to audit information provided by Control Tower.

Any third party tool can be used for auditing the data stored in this account

Can also use SNS for notification about changes to any governance or security policies

And use CloudWatch for monitoring landing zone-wide metrics

There is also account factory – which can be likened to a team of robots which create, modify or delete AWS according to business needs.

We could interact with them from both Control Tower console or via Service Catalog

Account Factory

It will create as many accounts as needed in the Custom OU called sandbox in a fully automated way

Configuration of these accounts are handled by Account Factory

From account and networking perspective, the baseline or cookie cutter configs are applied thus ensuring a consistent config across all AWS accounts within landing zone

Control Tower uses CFN under the hoods for much of this automation

Control Tower uses both AWS Config and SCP to implement account guardrails which detect drifts or divergences from governance standards or prevent the drifts from happening in the first place.

The action of provisioning also includes automatic applying of guardrails

Account administration permission can be given to any named user – making it true self service

Account and network standard configurable applied according organizational requirements like IP addressing of VPCs

Accounts can be closed or repurposed.

This whole process can be fully integrated with business SDLC using API if we need accounts provisioned according to the stage of app development, client demos, or software testing.

Landing Zone

Landing zone – A feature designed for anyone to implement Well Architected multi-account environment.

Home Region – the region where the product is initially deployed into.

Landing Zone is built by services like AWS Config, AWS Organizations, CFN etc. So basically it is a product which orchestrates the features of various AWS services

Security OU – Log Archive and Audit Accounts (Cloud trail and Config Logs)

Custom (Sandbox) OU – Less rigid security. Used for testing purposes

Uses IAM Identity Center for single-sign-on, ID federation – using existing identity stores to access AWS accounts

Provides monitoring and notifications using CloudWatch and SNS

Allows end user account provisioning via Service Catalog

GuardRails

Basically rules for multi-account governance

Three different types – mandatory, strongly recommended or elective

Mandatory rules are also applied compulsorily enforced

Strongly recommended ones are strongly recommended rules are given by AWS

Elective are optional and are for niche requirements

Two functional types – Preventative and Detective

Preventative – stops us from doing things – implemented using Service Control Policies

Examples of enforced rules are allow/deny regions or disallow bucket policy changes within accounts inside the Landing Zone.

The second functional way is detective. They are like compliance checks.They use AWS Config rules to check whether configuration of a service is according to best practice.

Three states – clear, in violation or not enabled.

Preventative rules will stop things from happening.

Detective rules will identify things

So they are an important security and governance feature in AWS