AWS Control Tower & Customization for Terraform

Much has been said and written about the cloud and the benefits it offers. However, with all these benefits, there are challenges with respect to faster cloud adoption, compliance, and security of the overall environment. Every organization that wants to migrate or implement workloads in the cloud has different needs and priorities, which means there’s no one way for adopting cloud best practices. However, a well-designed and documented execution of the AWS Control Tower is one of the recommended approaches.

What is AWS Control Tower and Its Business Need?

AWS Control Tower is the basic building block of the AWS cloud adoption environment and will act as an airport runway for your workload migration to the cloud. It renders an easy and secure way to set up and govern an AWS multi-account environment, following AWS best practices, by synthesizing the potential of various other AWS services like AWS Organizations, AWS Single Sign-on, and AWS Service Catalog, and constructs a landing zone in just under an hour.

AWS control tower can be adopted as a primary way to provision accounts and infrastructure, which enables you to protect your organization and accounts from drift, and facilitates account deployment/ governance while letting you effortlessly adhere to corporate standards and fulfill regulatory requirements.

Setting up a multi-account environment can take a significant amount of time, involving the configuration of multiple accounts and services. AWS Control Tower helps automate the provisioning of accounts and provides centralized control over security, monitoring, and logging.

Key benefits

• Centralized Logging: It enables CloudTrail logs in all provisioned accounts to send logs to a centralized S3 bucket in Log Archive account.
• Security: Control tower helps us enable a set of mandatory and recommended policies called GuardRails that can enforce rules via AWS Config in an AWS account.
• Single Sign-On: It also sets up AWS SSO across all the provisioned accounts. SSO can then be integrated with external IDP for seamless hybrid-user ID management and access.
• Cost Management: Consolidates billing across the AWS Organizations.
• VPC Provisioning: Automates the provisioning of VPC and its related resources in the newly provisioned AWS account. Control Tower leverages Account Factory and AWS Service Catalog

Our approach towards AWS Control Tower:

As a standard, our Control Tower-based deployment includes the following:

• Multi-account architecture with each AWS account specifically designated to the client’s business needs.
• “Network” account that consolidates most of the networking components such as Transit Gateway, VPCs, VPN, Direct Connect or Palo Alto
• “Shared Services” account that contains services or resources related to Active Directory, DNS and AWS DevOps services such as AWS CodeCommit & AWS CodePipeline. We utilize DevOps and Terraform for deploying resources within an account.
• Logs such as CloudTrail and VPC Flow logs are centrally managed in Amazon S3 buckets of “Log Archive” account.
• Setup mandatory and recommended Guardrails for compliance.
• AWS Security Hub is deployed in “Security” account to perform Cloud Security checks in all accounts. We follow “CIS AWS Foundations Benchmark” as a standard. Security Hub also provides a consolidated view and helps in remediation.
• Configure SSO with an existing external Identity Provider and few initial groups to get started.

Control Tower Customization for Terraform:

Based on our experiences with various clients, we have understood that every environment, their requirements, and business needs are different. A standard AWS Control Tower deployment may not be the go-to approach for all the clients we interact with. There were times when we had to customize the network design and other services in each of the accounts.

Customization of Control Tower can be done in a couple of ways, one such solution from AWS is: Customizations for AWS Control Tower. The solution uses Lambda, Step Functions, and CloudFormation StackSets for custom resource build. However, we have witnessed clients with specific preferences towards Terraform, it might be because their existing team has the required skillset, or they are multi-cloud. Hence, we developed a custom solution with Terraform and DevOps practices as its core.

A solution is an event-driven approach where Control Tower events are utilized to automate the necessary base infrastructure services required. The Control Tower event “CreateManagedAccount” from the Master account is sent to a custom bus in the “Shared Services” account, where a Lambda is used as a trigger to create AWS CodeCommit repositories to hold the Terraform code and AWS CodePipeline for IaC pipeline.

The Terraform code in the AWS CodePipeline repository can be customized according to the respective account architecture. Every time a new account is provisioned in the Control Tower, either a new repository or a branch can be created automatically. It also creates a respective pipeline to deploy the Terraform code. This gives way for 3 benefits:

1. Leverage Terraform to deploy AWS infrastructure
2. Customize the AWS accounts based on the architecture
3. Having the code repository gives benefits such as lifecycle management and version control of the infrastructure

Conclusion:

Customization of Control Tower deployment becomes necessary when we aim to achieve a specific Architecture Design. With Terraform as the primary IaC in our approach, the journey toward AWS becomes seamless for our customers. There has also been a recent Terraform-based solution from AWS I.e. AWS Control Tower Factory for Terraform. It uses a different approach; however, the core idea remains the same.

Thanks for reading this far, and good luck. I appreciate your comments/feedback.

Note: It has already been published here.

About The Author
Suraj Solanki
DevOps Engineer — II
LinkedIn: https://www.linkedin.com/in/suraj-solanki