Dependency management in AWS Control Tower Account Factory for Terraform (AFT)

Do you work with landing zones everyday like me? If so, maybe you’ve already heard that AWS just released a solution to manage landing zones. It uses Hashicorps Terraform, the AWS Control Tower Account Factory for Terraform (AFT), and today I want to dive into what this might mean for your (or your company’s) work with landing zones. 

My team at Nordcloud builds, maintains and delivers landing zone solutions. Because of this, I was actually one of the first to start exploring the possibilities of this new solution and discovering its benefits, as well as its potentially missing functionalities. In this post, I’m going to describe one of the latter and provide a possible workaround.

Today's question is: "How do you manage dependencies between account customisations in AFT?" Let’s jump in.

What is AFT?

This is going to be a bit of a mouthful. AWS Control Tower Account Factory for Terraform or AFT helps to prepare an automated pipeline for the provisioning and customisation of accounts created using AWS Control Tower. To put it simply, AFT creates the needed repositories and deployment pipelines to automate the management of accounts inside your organisation.

It works like this:

1. We install AFT and configure the CodeStar connection with your GIT repository
2. We then design Terraform account files and customisations scripts on your own repository
3. On each pushed GIT change, AWS triggers the procedure of accounts creation/ modification with the next implementation of customisation scripts
4. Global customisation scripts (applied on all accounts in the organisation) are invoked
5. Account customisation scripts (applied only on specific accounts) are invoked

What’s the Problem?

Account customisations using AFT only invoke the pipeline on a single AWS account. Below you can see the schema of an implementation of global and account customisation.

So, in case you want to prepare any relationships between accounts, then "Houston, we have a problem."

For example, you can create the AWS Transit Gateway on the network account, which will be shared across other accounts inside the organisation. Based on the implementation of the customisations schema, we have no glue between customisation pipelines. This is because each pipeline is responsible for managing a single account and by default there are no connections to other accounts.

First, let's figure out how to connect to another account.

Connection between accounts

To connect to the different accounts from Terraform you can use the providers. That way is ideal for us, but we still need a place for storing the shared data because even if we decide to connect to other accounts, we need to know their IDs.

In this case, we can take the controller account from which we are triggering all AFT actions. For the storage values, we can choose whatever we want: SSM Parameter Store, DynamoDB table, etc. In that instance, we have chosen the AWS Systems Manager Parameter Store, but any other will also fit.

Let's do this. We have a network account, the ID of which we need to share within the organisation. So, in account customisation scripts for the network account, we need to connect to the controller and put this value there.

Now, we can get the ID of our network account, which can be accessed from any customisation.
How can we do this? Easy, connect to the controller account and read parameter value.

Using this connection, we can perform any action we want. Then it’s time to prepare dependencies.

Preparation of dependencies

As we mentioned the AWS Transit Gateway in examples before, let's now apply it.

First, we need to create the AWS Transit Gateway and prepare AWS RAM for sharing.

Once we have outputs on the Terraform state file and know the account ID to which this state file belongs, we can read these values from the S3 bucket. We can then use it for the association, because we already know other data, like the S3 bucket for state files and the path to them (because AFT uses default ones). 

Great, so now we have the AWS Transit Gateway, created on the Network account customisation pipeline stage, and we have the association to it on our workload account. 

A few final observations

• This solution can be applied to any other resources on AWS if they need to be shared across a few accounts.
• Ultimately, the preparation of a powerful mechanism for automated rolling of accounts in the AWS organisation took an exciting step forward using Terraform.
• AFT allows us to combine resources and build connections between them on the fly, directly from our repository. This provides an additional layer of security for any Landing Zone change.

Join Us.

We need people who want to work at the cutting edge, get stuck into problems and be rewarded for success.

More on Careers