CfCT is a deployment framework that integrates with your Control Tower service deployment. It needs to be installed in the management account, in the same region where Control Tower was initially set up. It hooks onto the service events and runs a workflow that provisions SCP policies or AWS CloudFormation resources across account targets in your organization.
The framework is used to deploy two types of resources: SCP policies and CloudFormation StackSets. Each has a dedicated deployment workflow that is implemented through AWS Step Functions. User interaction with the framework happens through a manifest file that has a well-defined YAML format. Whenever the file is committed to version control, the framework picks up the changes and executes the pipeline.
We can look at Figure 11.4 to understand the different components involved in the deployment framework:
Figure 11.4 – Components of the CfCT framework (source: https://docs.aws.amazon.com)
The entire solution can be deployed as a CloudFormation template in your AWS management account. As you can see, there is a CodePipeline pipeline that pulls the most recent changes from the version control (S3 or CodeCommit) and triggers a CodeBuild project that validates the manifest file initially. If all looks good, the framework proceeds with an invocation for both the SCP Step Functions state machine and the CloudFormation Step Functions state machine. If you haven’t been exposed to the AWS Step Functions service before, it is a workflow orchestrator that helps you build programmable flows that invoke various AWS services to get a job done. Let’s look at an example of the manifest file that’s used by the framework to deploy resources in your Landing Zone:
—region: us-east-1 # Control Tower Home Regionversion: 2021-03-15resources:- name: test-preventive-guardrailsdescription: Prevent deleting or disabling resourcesresource_file: s3://marketplace-sa-resources-ct-us-east-1/ctlabs/ preventive-guardrails.jsondeploy_method: scpdeployment_targets:organizational_units:- Security- Sandbox……- name: create-iam-roleresource_file: s3://marketplace-sa-resources-ct-us-east-1/ctlabs/ describe-regions-iam-role.templatedeploy_method: stack_setdeployment_targets:organizational_units:- Security- Sandboxregions:- us-east-1
The manifest file answers three questions, represented by keys in the YAML structure:
- Resource_file: Where is the code that needs to be deployed?
- deploy_method: What needs to be deployed? This can have two values –scp or stack_set.
- deployment_targets: Where should the resource be deployed? Here, you can use individual accounts or OUs that represent a collection of accounts.
As soon as this file is committed into the Git repository tracked by the solution, the pipeline triggers, resulting in the SCP and the CloudFormation template being deployed in the target destinations – in this case, the security and sandbox OUs.
One benefit of using AWS-offered solutions is that you are covered by AWS Support, should the need arise. This is not the case with other custom implementations that you might develop.
Summary
We started this chapter by identifying the need for a multi-account structure and the benefits it provides when hosting multiple workloads in AWS. Multiple services, solutions, and deployment frameworks fulfill a certain need, but it’s important to understand that they are not going to help you just on their own. Some level of customization is always needed for organizations to implement their specific needs. With the needs and benefits clarified, we moved on to key considerations that you should have when designing a Landing Zone concept. We also looked at some best practices in the areas of multi-account structure, security and IAM, DevOps and Config management, and operations.
Toward the second half of this chapter, we took a deeper look into how AWS Control Tower works under the hood, and out-of-the-box integrations with the CfCT solution. One of the key benefits that customers get from these solutions is that they are supported by AWS, just as they would support any other service.
In the next chapter, Adhering to AWS Well-Architected Principles, we will investigate the key pillars of a solid foundation that you can consider for your application workloads.
Further reading
To learn more about the topics that were covered in this chapter, take a look at the following resources:
- AWS Deployment Framework (ADF): https://github.com/awslabs/aws-deployment-framework
- Account Factory for Terraform:https://docs.aws.amazon.com/controltower/ latest/userguide/aft-getting-started.html
- Best practices for OUs with AWS Organizations: https://aws.amazon.com/blogs/mt/ best-practices-for-organizational-units-with-aws-organizations/