Discover streamlining landing zone creation from the ground up using a low-code approach, optimising efficiency and reducing development complexities.
Introduction
Building a robust multi-account level infrastructure is imperative for all organisations that seek to scale their operations. The pivotal question arises: How do you effectively orchestrate account creation? Two predominant methods come into play—leveraging out-of-the-box solutions or opting for an in-house build. In this post, we’ll be reflecting on how we delve into constructing a comprehensive landing zone from the ground up on AWS.
Objectives
The objective was to establish a streamlined process for provisioning workload accounts on AWS, capable of supporting diverse business functions and global scalability. A key challenge was ensuring minimal development interaction, given the operations-centric nature of the team inheriting the landing zone.
Evaluating Options
Given the requirements, we had to be diligent to ensure the solution would bring value to the client by enabling them to increase their throughput. We performed an extensive exploration of solutions evaluating multiple landing zone solutions.
Using Architectural Design Records (ADRs), we carefully assessed tradeoffs between each solution. Below is a high-level summary of our findings.
Vanilla Control Tower
Pros:
- Boasts a straightforward and easy-to-handle management system, officially backed by AWS.
Cons:
- Lacks the option to incorporate custom security policies for Organizations, necessitating the use of infrastructure as code for customization.
AWS Landing Zone Accelerator (LZA)
Pros:
- Offers a seamless and quick setup, features modular configuration, embraces an open-source approach, and allows for extensive customizations.
Cons:
- Presents a potential risk of project abandonment and lacks GitHub support for configuration, relying solely on AWS CodeCommit.
Customisations for Control Tower (cfCT)
Pros:
- Swift setup facilitated by an open-source framework, with the added ability to integrate custom security policies.
Cons:
- Carries a potential risk of project abandonment, utilises a monolithic configuration file, lacks illustrative examples, and does not support GitHub.
Control Tower with Account Factory for Terraform
Pros:
- Delivers complete flexibility, leverages Terraform compatibility, ensures cloud vendor neutrality, and supports the implementation of custom CI/CD pipelines.
Cons:
- Mandates the creation and ongoing maintenance of code, making it a less expedient solution for deployment to end-users.
After rigorous proof of concepts, ADR drafting, and presenting options to key stakeholders, we confidently settled on the Landing Zone Accelerator (LZA).
Landing Zone Solution
The Landing Zone Accelerator (LZA) is an open-source solution built and offered by Amazon. Developed using Amazon’s Cloud Development Kit and powered by Typescript, it forms the backbone of building Landing Zones on AWS. At its core, it provides a landing zone that not only aligns with industry best practices and compliance standards but also offers a low-code solution. By leveraging the capabilities of LZA, infrastructure adheres to the highest standards of compliance, ensuring a secure and efficient environment for operations.
Selecting LZA allowed us to move extremely fast due to providing an out-of-the-box solution that required minimal coding. This meant that we could provision production accounts that had best security practices baked in in a matter of weeks.
Implementation
The solution leverages various AWS services to streamline its process. It set up CloudFormation stacks to establish essential components within its architecture (illustrated in Figure 1). These components encompass AWS CodeCommit for configuration, CodePipeline for Continuous Deployment, CodeBuild for executing diverse tasks through multiple jobs, such as creating accounts or Organisational Units (OUs), S3 buckets for storing logs, lambda functions for auxiliary tasks and KMS for encryption. To deploy the architecture, Amazon offers a CloudFormation template accessible online. We had to simply import this template into the management account, and wait approximately 40 minutes for CloudFormation to create all the vital components illustrated in the accompanying diagram.
LZA uses a CodeCommit repository as the single source of truth to deploy changes to landing zones. It requires storing landing zone configuration in an AWS Code commit repository. It shards six YAML files into different areas of interest to represent the landing zone. By sharing each file, it allowed us to adhere to best design principles such as Single Responsibility improving the overall management of our landing zones.
The files allow you to define configuration in a declarative manner to create AWS Accounts, Organisation Units, Groups, IAM Policies, Security Control Policies (SCPs), Tagging policies, Permission sets and many more. This meant that you could fully manage your complete landing zone by only interacting with a few Yaml files in a GitOps fashion. Figure 3 below denotes an example of creating accounts using version-controlled configuration.
Customisation
For our use case, we went along with the recommended approach to deploy LZA with Control Tower setup (CT). This allowed us to leverage the innate drift detection capabilities that CT provides.
Github
While LZA offers a robust out-of-the-box solution, our hands were tied to using AWS CodeCommit, posing a challenge for a client deeply entrenched in GitHub practices. Adapting to CodeCommit would have necessitated a significant cultural shift.
To alleviate this problem, LZA provides a way you can extend the solution seamlessly without the need to fork the project. You simply add a cloud formation template that can be baked as part of the pipeline.
To implement this, we augmented the solution by leveraging the customizations.yaml. This enabled LZA to orchestrate the setup of an OpenID Connect (OIDC) provider as an integral part of the CodeCommit pipeline. This provider was configured to trust the GitHub repository we had created, ensuring integration between LZA configuration in CodeCommit and GitHub repositories. Driving this customization, we strategically set up adaptations around GitHub, preventing the need to use CodeCommit for managing configuration in version control. This decision proved to be a game-changer, as the client was already well-versed in GitHub workflows. The integration made their transition tenfold smoother. GitHub could now be used as the single point of contact for managing the landing zone.
Validation
To enhance the solution even further, our focus shifted towards elevating the Software Development Life Cycle. LZA comes equipped with tools designed to validate configuration for correctness. Traditionally, these tools ran during the pipeline process, but we identified an opportunity for improvement.
Recognizing the need for fast feedback, we implemented Continuous Integration (CI) checks that run on pull requests. This approach eliminates the delay of waiting for the pipeline to complete only to discover syntax errors or references to non-existent accounts. This provides extremely slow feedback to operators administering the landing zone which is not ideal.
Our goal was to provide rapid feedback to clients and contributors actively involved in landing zone changes. These CI checks go beyond just the LZA validator tool, extending to a comprehensive suite of validation mechanisms. This includes running YAML, JSON, and CloudFormation linters, and meticulously scanning for any malformed errors in policies or templates. The introduction of these CI checks ensures an agile and responsive development environment, minimising downtime and significantly improving the efficiency of the entire SDLC process.
Lessons Learned
Developing a landing zone on AWS with stringent requirements has been remarkably smooth, but valuable lessons have emerged from this experience.
One key takeaway is the recognition that building a gold-templated solution from scratch may not always be the optimal approach. It’s prudent to first explore how others have addressed similar challenges and learn from their solutions.
Attempting to force a cultural shift within teams can be counterproductive and may serve as an anti-pattern going forward. Instead, the focus should be on providing solutions that empower teams to enhance their throughput without imposing drastic changes in established workflows. Opting for a no-code solution is particularly advantageous, as it significantly reduces internal development costs, enabling more efficient and cost-effective implementations.
While engineers often have a natural inclination to build, it’s crucial to assess whether a solution may be over-engineered for the given requirements. Striking a balance between functionality and simplicity ensures that the solution meets the desired objectives without unnecessary complexity.
Lastly, leveraging a no-code solution not only reduces development time but also minimises the time spent on documentation for handover activities, contributing to a more streamlined and efficient process.
Summary
In conclusion, the journey to establish a robust multi-account infrastructure on AWS involved a strategic choice in favour of the Landing Zone Accelerator (LZA). Leveraging various AWS services, including CloudFormation, CodeCommit, and CodePipeline, our implementation streamlined the provisioning of secure and compliant workload accounts, adhering to best practices and low-code principles. Notably, customisations facilitated seamless integration with GitHub, mitigating the need for a significant cultural shift towards AWS CodeCommit. To enhance the Software Development Life Cycle (SDLC), we introduced Continuous Integration (CI) checks, running on pull requests, for immediate feedback to contributors. These checks, inclusive of the LZA validator tool and linter for YAML, JSON, and CloudFormation, significantly improved the efficiency of the development process, providing a comprehensive solution for scalable and operations-centric infrastructure.