Introduction
AWS Control Tower is a service that is intended for organizations with multiple accounts and teams who are looking for the easiest way to set up their new multi-account AWS environment and govern at scale.
AWS Control Tower enables you to enforce and manage governance rules for security, operations, and compliance at scale across all your organizations and accounts in the AWS Cloud. It makes sure that the organization is compliant with established policies while builders provision new AWS accounts quickly in a few clicks or none at all.
Using AWS Control Tower, cloud administrators can set up an automated landing zone that employs best-practices blueprints such as configuring multi-account structure using AWS Organizations, managing user identities and federated access with AWS Single Sign-on, enabling account provisioning through AWS Service Catalog, and creating a centralized log archive using AWS CloudTrail and AWS Config. For ongoing governance, they can enable pre-configured guardrails - clearly defined rules for security, operations, and compliance - that prevent deployment of resources that don't conform to policies and continuously monitor deployed resources for non-conformance. AWS Control Tower's dashboard provides centralized visibility into their AWS environment including accounts provisioned, guardrails enabled, and the compliance status of accounts.
One of the best features of AWS Control Tower is that you can use it with a pre-existing AWS Organization.
Control Tower Structure
This is the Default structure for when you create a Control Tower. It has the Core OU with the Audit Account and Log Archive Account. Of course, you can add other types of accounts that your Organization uses as Core Accounts like Inbound, Outbound, and Foundation into this OU.
Account Factory
A configurable account baseline using Infrastructure-as-code (IaC) principle is set up as a self-service AWS Service Catalog product that can be used to create new AWS accounts. The account factory helps standardize the provisioning of new accounts with pre-approved account configurations and standards to help the organizations jumpstart their AWS journey with an account created out of box to meet Organization's security best practices.
https://controltower.aws-management.tools/automation/aft_setup/
Customization for Control Tower
Every Organization has its own process, so it would be normal to need a Customization process on what the AWS Control Tower deploys.
For that, we have the Customizations for Control Tower (CFCT).
It allows companies to update the Environment setup up of the accounts that come from the Account Factory.
Examples:
- Add SSM parameter in the account-specific for each environment, or network, automation to use
- Network setup(VPC, Subnet, Internet Gateway, VPC endpoints…)
- Permission Sets for the account
- Adding account info in a Database
- AWS Config Rules
- Creation of Roles
Any kind of resource creation by the Organization Standards need to be done in this process, or at least the basic for the account to be functional.
Multi-Account Strategy
The AWS best practices for a well-architected environment recommend that you should separate your resources and workloads into multiple AWS accounts. Multi-Account Strategy offers workloads categorization, as well as blast radius reduction when things go wrong.
An AWS account provides the ability to isolate resources and to contain security threats for your AWS workloads. An account also provides a mechanism for billing and for governance of a workload environment.
Guidelines to set up a well-architected environment:
- Multiple AWS accounts
- Multiple organizational units (OUs)
- A well-planned structure
Examples:
Deploying Additional Resources with AWS Service Catalog
A while ago I have written an article about the AWS Service Catalog, you can take a look here and understand a little better about it and how to implement it without using AWS Control Tower.
The AWS Control Tower has a feature where you can share Service Catalog Portfolios through the AWS organization(you can specify an OU or use the root OU for all), just like the "Organizational Service" in one of the sections below.
GuardRails
For the GuardRails section, AWS Control Tower offers some mandatory and some optional. You need to validate in case of any conflicts that could happen with the GuardRails that your company has already deployed with the ones deployed by the AWS Control Tower Service.
- Mandatory GuardRails: Mandatory GuardRails are enabled by default when you set up your landing zone and cannot be disabled.
- Strongly Recommended GuardRails: Strongly Recommended GuardRails are based on best practices for well-architect multi-account environments. They are not enabled by default and can be disabled at any time.
- Elective GuardRails: Elective GuardRails enabled your organization to lock down or track attempts at performing commonly restricted actions in an AWS environment Don't forget that these are GuardRails available when using AWS Control Tower, but you can also use Third-Party GuardRails like Cloud Custodian, Turbot to ensure security measures and compliances across your AWS environment.
Organizational Units(OU) and Sub Organizational Units(Sub OU)
And for non Organizational Core accounts, the organization can have as many kinds of Organization Units as it needs to organize and manage the AWS Accounts.
PS: OUs in Control Tower have a limitation of 300 accounts per OU, to workaround that you can create SubOU inside OUs
Core OU / Shared Accounts
In AWS Control Tower, these Core Accounts in the environment are provisioned during the Control Tower setup.
- Audit Account: Is a restricted account that’s designed to give your security and compliance teams read and write access to all accounts in your landing zone. From the audit account, you have programmatic access to review accounts, by means of a role that is granted to Lambda functions only. The audit account does not allow you to log in to other accounts manually, This usually is done by request, IAM Team or Organization automation.
- Log Archive Account: Works as a repository for logs of API activities and resource configurations from all accounts in the Control Tower environment. PS: It is not recommended to run any type of production workload from an AWS Control Tower management account. You can create a separate AWS Control Tower account to run your workloads.
Organizational Services
All of the services below are enabled in the Master of each Control Tower and support delegation to other accounts(Only SCPs that don’t have this feature).
- GuardDuty
- Security Hub
- AWS Config
- AWS Service Control Policies (SCPs). I have writeen this AWS Article about it
- AWS Service Catalog
Control Tower Limitations
- Email addresses of shared accounts in the Security OU can be changed, but you must update your landing zone to see these changes in the AWS Control Tower console.
- A limit of 5 SCPs per OU applies to OUs in your AWS Control Tower landing zone.
- Existing OUs with over 300 accounts cannot be registered or re-registered in AWS Control Tower (This is why we use SubOUs in OUs).
And of course, there are quotas for all the integrated services with Control Tower:
- AWS CloudFormation — AWS CloudFormation Quotas
- AWS CloudTrail — Quotas in AWS CloudTrail
- Amazon CloudWatch — CloudWatch Quotas
- AWS Config — AWS Config Quotas
- AWS Identity and Access Management — Quotas for IAM Entities and Objects
- AWS Lambda — AWS Lambda Quotas
- AWS Organizations — Quotas for AWS Organizations
- Amazon Simple Storage Service — Bucket Restrictions and Quotas
- AWS Service Catalog — AWS Service Catalog Default Service Quotas
- AWS IAM Identity Center (successor to AWS Single Sign-On) -Quotas in IAM Identity Center
- Amazon Simple Notification Service — Amazon SNS Quotas
- AWS Step Functions — AWS Step Functions Quotas Source: https://docs.aws.amazon.com/controltower/latest/userguide/limits.html
Control Tower Workshops
- AWS Management Tools
- Control Tower
- Account Factory
- Account Factory — Enroll Existing Accounts
- Livecycle Events
Conclusion
AWS Control Tower is a great AWS Service, but it is a rough service. Your Organization needs a certain maturity to use it.
If your company applies to it, can afford and has AWS-specialized employees, this is the best solution for your Organization to use. Otherwise, the AWS Landing Zone will suffice.
There are always several ways to execute something in AWS, you just need to see the best for your Organization’s standards.
Feel free to comment about it and I hope this article can come in handy!
Top comments (0)