Set up an AWS Landing Zone with the Landing Zone Accelerator (LZA), which is a cloud foundation to support highly-regulated workloads and complex compliance requirements. But can also be used for not-so-highly-regulated workloads.
TL;DR & Links
So what is the LZA:
The Landing Zone Accelerator on AWS solution deploys a cloud foundation that is architected to align with AWS best practices and multiple global compliance frameworks. With this solution, customers with highly-regulated workloads and complex compliance requirements can better manage and govern their multi-account environment. When used in coordination with other AWS services, it provides a comprehensive low-code solution across 35+ AWS services.
The background
Together with other folks, I co-built superwerker back in May 2020 when ControlTower was only one year old. Back then AWS did not provide such tooling for an automatic setup of a Landing Zone
which we expected. Ok, first: what is a Landing Zone:
A Landing Zone is a well-architected multi-account AWS environment that is scalable, secure and fulfills your compliance and governance requirements.
At the end of 2022, we started migrating superwerker to cdk, which went very smoothly and at a fast pace.
However, we struggled with our testing setup, as we wanted to have a fresh AWS management
account for each test run. There is no automation yet for this use case. We also did not want to have a reusable pool of AWS management accounts, as we could not ensure that this will give false positive test results. Also, as non-AWS internal engineers, we did not have possibilities
like disposable AWS accounts at scale.
It started when the following discussion in the superwerker GitHub repository came up, which got my attention towards the LZA tool/solution. Here the snippet of my answer:
As said in my answer to the linked discussion above:
However, when we started building superwerker back in June 2020, there was already ControlTower, however no such thing, like automatically adding SecurityHub and GuardDuty member accounts, etc. So we built it back in time 😃
The LZA solution
Image credit from AWS. I will not go into much detail now here as the official documentation here explains it already quite well.
Furthermore, my friend Kadir Keles already published two great posts about the LZA in theory and in action from a platform engineer’s or operator’s perspective.
You find them here:
From my point of view, I want to add two things
- the cost are
~100$with a minimal setup, whereas withsuperwerker, we are~10$per month. The big driver isKMShere, as the LZA create 6 KMS key per account. - For the email pattern in general for the AWS root mail in the LZA setup, I’d suggest using aliases that are not guessable, such as
aws-roots+<uuid>@acme.com, e.g.,aws-roots+audit-faeb-0c4cd0853ba9@acme.com. One detail about the LZA is that it expects the mail addresses to be lowercase in theaccount-config.ymland must not have more than 52 characters
workloadAccounts:
- name: John-Doe
description: John's test account
email: aws-roots+john-doe-faeb-0c4cd0853ba9@acme.com
organizationalUnit: Sandbox
Conclusion
In 2020 we would have wished for AWS to provide a tool to do us all this heavy lifting. By the end of 2022 AWS built it with an entire development team behind it.
In my opinion, the LZA is a superseded of superwerker or its version v2.0. However, not to forget superwerker is more lightweight, and more cost-effective, as it targets non-regulated environments.
Using my experience with superwerker, aws-cdk and AWS governance services, such as ControlTower, I started reporting issues, such as #158, when there was a problem with onboarding
an AWS account with EBS volume encryption in the security-config.yaml and
certain service-linked roles were already present.
Stay tuned for more in-depth posts about the LZA.
Cheers
Like what you read? You can hire me, or drop me a message to see which services 💻 may help you 👇
