Introduction to Customizations for Control Tower (CfCT)

CfCT streamlines AWS account setup by converting your manual checklist into a consistent, automated pipeline that applies your baselines across every account.

The Situation…

Some organizations begin their transition to the cloud in a straightforward manner, migrating to AWS when their on-premises VMware cluster and/or physical data center has reached capacity, and there is either no interest or desire to purchase additional hardware to accommodate the workloads necessary to support current or future business initiatives.

Many times, the support teams of these organizations have no prior AWS background, no experience with infrastructure-as-code, and no Git workflows. They start small by deploying a Control Tower landing zone, creating a VPC with CloudFormation, setting up a VPN back to the on-prem datacenter, and launching a few EC2 instances.

But growth in AWS doesn’t always start with big plans. In a recent case, an organization originally believed they only needed a couple of EC2 instances in a single account. But as they used the platform and saw what AWS made possible, their use case quickly evolved from simple to more sophisticated. Within a short period, they expanded into a multi-account environment and began adopting services like centralized firewalls, Transit Gateway, custom route tables, Route 53 Outbound Endpoints, VPC Endpoints, not to mention the IAM roles and security groups that were created to support their management and security requirements. What started as one CloudFormation template became several. In just a few months, they went from having no AWS or IaC experience to desiring an automated way to consistently deploy baseline infrastructure across accounts.

What did they do? In this case, they selected AWS Customizations for Control Tower (CfCT) to apply their baseline infrastructure and policies across all accounts.

Customizations for Control Tower (CfCT)

AWS Customizations for Control Tower (CfCT) is an open-source, AWS-supported solution that automates the deployment of infrastructure, configuration, and shared services across your AWS organization. It provides a standardized and repeatable way to apply account baselines using CloudFormation templates, eliminating the need to configure each new account “by hand”.

At an extremely high level, CfCT works in this way:

1. Create a Git repository that will ultimately contain your CloudFormation templates, parameter files, and a manifest.yaml configuration file
2. Deploy the CfCT solution in the Management Account using its provided CloudFormation template (use link above).
3. CfCT sets up an AWS CodePipeline that monitors your repository for commits to the main branch. (the monitored branch is specified during the CfCT deployment, main is the default and typical choice)
4. Define the resources you want deployed—VPCs, networking, IAM, security groups, etc.—using templates and parameter files.
5. When you commit changes to main, CfCT automatically deploys the CloudFormation templates to the specified OUs, accounts, and regions.

An example GitHub CfCT directory structure is shown below:

├── manifest.yaml
├── templates
│ ├── network-resources.yaml
│ ├── account-resources.yaml
├── parameters
│ ├── network-resources-dev-acct.json
│ ├── network-resources-prod-acct.json
│ ├── account-resources-dev-acct.json
│ └── account-resources-prod-acct.json
└── README.md

Basically, store CloudFormation templates in the templates directory and their corresponding parameters in the parameters directory. The manifest.yaml file functions as the blueprint, defining which templates to apply, which accounts or OUs they target, and which parameters to use. A sample manifest.yaml file is shown below:

version: 2021-03-15
region: us-east-1 #default deployment region
resources:
  - name: create-network-dev
    description: "Creates VPC and subnets for DEV AWS account"
    resource_file: templates/network-resources.yaml
    parameter_file: parameters/network-resources-dev-acct.json
    deploy_method: stack_set
    deployment_targets:
      accounts:
        - "123867530912"
    regions:
      - us-east-1 

  - name: create-network-prod
    description: "Creates VPC and subnets for PROD AWS account"
    resource_file: templates/network-resources.yaml
    parameter_file: parameters/network-resources-prod-acct.json
    deploy_method: stack_set
    deployment_targets:
      accounts:
        - "567890123456"
    regions:
      - us-east-1	  
	  
  - name: account-resources-dev
    description: "Creates DEV account resources"
    resource_file: templates/account-resources.yaml
    parameter_file: parameters/account-resources-dev-acct.json
    deploy_method: stack_set
    deployment_targets:
      accounts:
        - "123867530912"
    regions:
      - us-east-1

  - name: account-resources-prod
    description: "Creates PROD account resources"
    resource_file: templates/account-resources.yaml
    parameter_file: parameters/account-resources-prod-acct.json
    deploy_method: stack_set
    deployment_targets:
      accounts:
        - "567890123456"
    regions:
      - us-east-1

With the templates, parameter files, and manifest defined, CfCT now has a complete map of what to deploy and where to deploy it. From this point on, every change committed to the main branch is automatically packaged and deployed through the CfCT pipeline to the specified OUs and accounts.

More to come…

This overview scratches the surface of CfCT but that’s my intent with this post, to raise awareness and provide a basic overview. I’ve got to end this post or it’ll become too long for any real value. As I worked with CfCT, I started visualizing it similar to how I do EC2 Image Builder. With EC2 Image Builder, you define a baseline image, add components, harden to your organizations specifications, etc. to produce a reliable and consistent AMI for use with EC2-based workloads. CfCT uses a similar pattern to define baseline infrastructure that every AWS account in your environment should have and then consistently deploys that infrastructure throughout your entire AWS organization. Just as Image Builder ensures every AMI is standardized and compliant, CfCT ensures every AWS account is aligned with you organizational standards.

In future articles, I plan to provide more detail on deploying the solution, using CfCT to tighten CloudFormation templates using CfCT’s built-in validations, troubleshooting some pipeline failures, and setting up GitHub workflows to do validation checks before the pipeline executes…I got tired of waiting for pipeline runs to see errors so I used a GitHub workflow to do several validation checks before merging the PR.

By the end of all this, I hope you’ll have a better idea of how you may be able to use CfCT in your own environment.