If you are thinking of setting up a landing zone using ADF in AWS you will need to read this. And why? Because I will tell you why you need to set up two landing zones. And how you can use them to test your landing zones.

What is a landing zone?

A landing zone is a solution that help you to set up a secure, multi-account AWS environment. There are a couple of ways how you can do this, for example:

• AWS Landing Zone (predecessor of AWS Control Tower)
• AWS Control Tower
• AWS Deployment Framework
• Build your own… In this post I am focussing on ADF. The benefit of ADF over AWS Control Tower is that you have more control over the framework. All resources run in your accounts and are under your control. AWS Control Tower is a managed service by AWS. Giving less flexibility but remove maintenance burden.

What is ADF?

From the ADF documentation:

The AWS Deployment Framework (ADF) is an extensive and flexible framework to manage and deploy resources across multiple AWS accounts and regions within an AWS Organization.

So a simple example of this would be, if you need to provide a new DTAP environment for a new workload. You will add some details to a YAML file and commit/push/review/merge it. Then you ADF does its magic. It will create the AWS Accounts on your behalf and bootstrap them. And you end up with a couple of AWS Accounts that have:

• A pre-provisioned network setup.
• Security controls
• etc etc Please note, you need to build what it bootstraps into these accounts your self. ADF only makes it easy to manage what templates are deployed where.

So what is there to test?

Within AWS Organizations you can apply Service control policies (SCPs). All AWS Accounts under the OU (Organization Unit) with the SCP will be subjective to this SCP. What if you need to make a change in this SCP? How can you test this change?

SCPs are not the only things you might want to test. Remember that I mentioned that ADF is also bootstrapping the accounts? That could be a VPC with subnets for networking. How do you ensure that the change that you made works as intended?
When merging to your main branch. It will trigger a rollout process depending on your configuration.

The solution

You can solve this by rolling out a "test" organization. It will mirror your production organization. But you can scope it down to a smaller set. As long as you cover the cases that are important to your organization. The idea is that when you make a change you first deploy it on the "test" organization. Once deployed you do some tests and roll it out in production.
Setting up a "test" organization when you already have a full-fledged landing zone. That is harder than doing it from the beginning. It also helps with the mindset of the team maintaining of the landing zone that there is a "test" environment.
And depending on your own use-case you can make a lot of different choices how to set this up. For example, moving the dev and test environments to the "test" organization.

Conclusion

Start thinking about how you can test your landing zone. Setting up 2 landing zones will help you with that. Use a test driven approach when building your landing zone. It will be much harder to add testing afterwards.