A critical first step on your AWS journey is launching and configuring a robust multi-account “landing zone” with best practices for security and governance baked in. Over the years, many tools have sprung up to support this need. Currently, the two most common approaches we see and use at Trek10 are Control Tower (the AWS native service) & OrgFormation (an open-source solution).
If you are configuring AWS accounts from scratch you may be wondering, which is the best fit for me? These are two very different approaches and both are great fits for the right situation. In this post, we will lay out some of the pros and cons to help you make a more informed decision.
If you have come to this post there’s a good chance that you already know about Control Tower and OrgFormation, but if you don’t, you’re either new to AWS or have found yourself exhausted scrolling endlessly through social media at 2:00 AM to realize you have wasted three hours and need to go to bed having learned something new, so have no worries. We are here to help you understand the pros and cons of using both of these tools.
AWS Control Tower
AWS Control Tower is an AWS service that provides a means to set up and govern a secure, multi-account AWS environment based on AWS best practices. With AWS Control Tower, we can provision new AWS accounts easily and ensure your accounts conform to your company-wide policies. It functions as a pre-baked layer of abstraction on top of AWS Organizations, AWS Config, CloudTrail, CloudFormation, and a few other services to provide the features that are included in this offering.
OrgFormation is an open source project that communicates with the AWS API to perform assorted functions to configure a multi-account AWS environment with best practices. It primarily works in conjunction with AWS Organizations which provides a way for customers to manage accounts centrally, allowing them to set and apply security control policies, and manage billing and costs across accounts. OrgFormation is an open-source solution that is not officially maintained by AWS but has abundant community support.
Both Control Tower and OrgFormation have similar functionalities but many important differences.
Control Tower vs. OrgFormation
The section below draws a good comparison between Control Tower and Org Formation.
Control Tower Pros
This is an AWS-native solution and it is likely to receive very long-term support.
The setup is easier because of the user-friendly GUI on the AWS console that provides a semi-guided approach to setting up your landing zone.
All of the setup and configurations are managed through the AWS console which makes it much easier to own and manage over time.
There is no requirement to code any aspect of the platform and the console hides all the complexity of owning and managing your multi-account best practices configuration.
Control Tower Cons
It is not code-defined and can not be managed as Infrastructure as Code.
There are significant limitations to using Control Tower, and it is not very customizable. Some of the limitations with Control Tower are:
There is no ability to build any form of Continuous Integration on the account setup
There is a limit of 5 SCPs per Organizational Units in your Landing Zone
You cannot organize your Control Tower with nested Organizational Units
You must allow an AWS SSO configuration to exist in your account. If your organization decides against the use of AWS SSO for compliance or any other reason, there’s no way to get around AWS SSO existing in your organization, as ControlTower will create it and require that it’s there before you can perform any operations
Each operation to your Control Tower landing zone (creating accounts, applying a guardrail, changing your landing zone configuration, etc) will take around an hour. These types of operations can only be performed one at a time, so it can take a very long time to complete the creation and configuration of your landing zone.
Any out-of-scope changes that are made usually result in errors on the Control Tower console. These errors would need to be fixed before continuing further. The fixing period usually requires a waiting time of up to an hour for all the changes to propagate and they can not be done in parallel.
Bringing existing accounts into Control Tower is challenging. Control Tower has many prerequisites that need to be met before an account can be added. Some of these prerequisites are:
The account must not have an AWS Config configuration recorder or delivery channel.
The account must have a role, with the correct permissions and trust policies in place. Otherwise, enrollment will fail. Pro Tip: there might be SCPs enforced on the account that might prevent this role from being deployed. In this case, the SCPs need to be altered to allow for provisioning this role. This modification would show an error on the Control Tower console and after the role is deployed the SCP would need to be reverted and Control Tower would need to be fixed.
Role Name: AWSControlTowerExecution Role Permission: AdministratorAccess (AWS managed policy) Role Trust Policy:
This is code-defined and can be managed as Infrastructure-as-Code. The entire organization structure, including organizational units (in any arrangement), can also be defined as IaC.
There are scriptable sets of tasks such as updating organization structure, updating CloudFormation stacks across your organization, registering CloudFormation resource providers, and even deploying Serverless Framework or AWS CDK applications. These operations are all orchestrated in a declarative manner via OrgFormation task files. It also supports dynamic OrgFormation-Annotated CloudFormation. This means that it allows you to define bindings to deploy infrastructure to accounts and regions dynamically based on tags, organizational units, or account enumeration. It supports the ability to reference resources defined across accounts and across regions within the same template ensuring everything is defined and orchestrated through IaC.
It is community-managed and not backed by AWS, so there is no guaranteed long-term support for it. The direction the tool takes is determined by the maintainers, not AWS.
OrgFormation-annotated templates are not portable. This means that these templates will only work with OrgFormation, and not CloudFormation. CloudFormation templates can be used with OrgFormation. The OrgFormation annotations are just there so you can dynamically define resources that span more than one account. One example is that you could define an AWS::CloudTrail::Trail resource and an AWS::S3::Bucket resource in the same template, but targeting the bucket to deploy to a log archive account and the trail to deploy to every other account, an example of this is shown below:
Hopefully the point-to-point comparison of Control Tower and OrgFormation has helped you in deciding which to choose for your specific need, however, if you are still confused provided below is a recommendation based on your company profile.
are new to AWS
are not comfortable with infrastructure as code and a command line interface
want out-of-the-box best practices in security and governance on AWS
are comfortable using the graphical user interface to make all changes
Control Tower would be a good fit for you.
have more specific security needs that may be hindered by the framework provided by Control Tower
prefer managing Infrastructure as Code
prefer to have a CI/CD process to your infrastructure
OrgFormation would be a good fit for you.
Hope this post helps you in choosing the right tool for account management and governance!