# The Landing Zone Accelerator turns a Control Tower landing zone into CDK code > The Landing Zone Accelerator on AWS is an open source AWS CDK project that deploys a multi-account foundation for highly regulated workloads, with configuration files driving governance controls, networking and account creation across more than 35 AWS services. The README is explicit that it does not make you compliant, and that a web console for configuring it is still a future package. **awslabs/landing-zone-accelerator-on-aws** — Deploy a multi-account cloud foundation to support highly-regulated workloads and complex compliance requirements. - Repository: https://github.com/awslabs/landing-zone-accelerator-on-aws - Website: https://aws.amazon.com/solutions/implementations/landing-zone-accelerator-on-aws/ - Stars: 832 · Forks: 684 - Language: TypeScript - License: Apache-2.0 - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/awslabs-landing-zone-accelerator-on-aws ## A foundation on top of Control Tower The Landing Zone Accelerator on AWS, abbreviated LZA in the README, is architected to align with AWS best practices and in conformance with multiple global compliance frameworks. The recommendation to customers is to deploy AWS Control Tower as the foundational landing zone and then enhance the landing zone capabilities with the accelerator. The relationship matters. This is not a replacement for Control Tower. It is a layer that sits on top of an account factory and an organization structure you already have, adding governance, security services and networking topology, and generating additional workload accounts through the Control Tower Account Factory. What you get for that is a low-code solution across 35+ AWS services to manage and govern a multi-account environment. The README describes two complementary capabilities, establishing platform readiness with security, compliance and operational capabilities. The delivery model is infrastructure as code, and the project is installed directly into your environment so you have full access to the solution as code. It is built with the AWS Cloud Development Kit, and a simplified set of configuration files is what you actually edit. Through those files you configure additional functionality, controls and security services such as AWS Managed Config Rules and AWS Security Hub, and you manage the foundational networking topology, with VPCs, Transit Gateways and Network Firewall named in the README. The licence is Apache-2.0, the primary language is TypeScript, and the last push to the default branch was on 2026-10-21. The default branch is release/v1.16.3, which is a branch-per-release model rather than a trunk, and the release history shows v1.16.1 on 2026-08-21, v1.16.2 on 2026-09-02 and v1.16.3 on 2026-09-16. ## The package structure and who owns what The README documents the monorepo as a list of packages, and the split is the clearest description of the system. @aws-accelerator/accelerator is a CDK application and the core of the solution, containing all the stack definitions and deployment pipelines, plus the CDK Toolkit orchestration. @aws-accelerator/config is a pure TypeScript library with the modules that manage the accelerator configuration files. Keeping that separate from the stacks is what lets you change configuration without touching deployment code. @aws-accelerator/constructs holds the L2 and L3 constructs built to support accelerator actions, such as creating an AWS Organizational Unit or a VPC. The README is specific about their intent: they are meant to be fully reusable, independent of the accelerator, and they do not directly access the accelerator configuration files. CentralLogsBucket is the named example, an S3 bucket configured with a customer managed key and with the key and bucket policies that let services and accounts in the organization publish logs to it. @aws-accelerator/installer is a CDK application that defines the installer stack, and @aws-accelerator/utils holds the common utilities and types the other packages need, with throttling and backoff for AWS SDK calls as the example. Two more sit under a different scope. @aws-cdk-extensions/cdk-extensions contains L2 constructs that extend the CDK itself, developed locally in this repository at first and then submitted upstream to the CDK project as a pull request. @aws-cdk-extensions/tester is the accelerator tester CDK app, which creates AWS Config custom rules for every test case defined in the test case manifest file. That last package is the one to notice. It turns the solution's expectations into machine-checked rules, which is how a deployment can be verified rather than assumed. ## Configuration files today, a console later The configuration model is deliberately file based. The README describes a simplified set of configuration files through which you configure additional functionality, controls and security services, and the @aws-accelerator/config package is the pure TypeScript library that manages those files. The directory listing at the top of the repository backs this up. There is a Config directory at the root, alongside deployment and reference directories, a source directory for the packages, a container directory, a solution-manifest.yaml, and documentation files such as FAQ.md, DEVELOPING.md, CONTRIBUTING.md, SECURITY.md and CHANGELOG.md. The README recommends reviewing the implementation guide for details on deployment, customization and maintenance of the solution and its included sample configuration files. A graphical console exists only in the plan. The @aws-accelerator/ui package is marked as future, and described as a web application that utilizes the aws-ui-components library to present a console to configure the accelerator. So the current workflow for an adopter is to write configuration files, run the CDK application, and read the documentation, not to click through a wizard. There is one housekeeping note that matters for anyone following the README alone. The installation and configuration reference documentation that used to live in the README has been migrated to the GitHub Pages site, and the README recommends reviewing both that resource and the Implementation Guide for deployment, customization and maintenance details. In other words, the README is now the entry point and the reference has moved. ## What it provisions, and what it costs The billing model is simple and worth stating before anything else. There are no additional charges or upfront commitments required to use the accelerator. You pay only for the AWS services enabled in order to set up your platform and operate your controls. The project is a deployment tool that stands up infrastructure you then pay for, and the licensing is Apache-2.0 with copyright Amazon.com, Inc. or its affiliates. What you actually get, from the feature list, is a landing zone that includes governance controls through AWS Managed Config Rules, security findings through AWS Security Hub, a networking topology of VPCs, Transit Gateways and Network Firewall, and account generation through the Account Factory. That is the difference between a landing zone that exists and a landing zone that is governed, and the 35+ services figure is the breadth of that surface. The solution also reaches beyond the commercial partition. The README states that it can support non-standard AWS partitions, including AWS GovCloud (US), and the US Secret and Top Secret regions. For a project that is mostly about regulated workloads, that is a load-bearing capability rather than a footnote, since the code and the control models have to work in partitions where the service catalogue differs. One more operational fact is stated in the README. The solution collects anonymized operational metrics to help AWS improve the quality of features of the solution, and the implementation guide has a page on the collection of operational metrics including how to disable the capability. That is worth deciding about before the first deployment rather than after. ## The disclaimer that defines the scope The most important paragraph in the README is the warning, and it is worth quoting because it governs how the whole project should be evaluated. The solution will not, by itself, make you compliant. It provides the foundational infrastructure from which additional complementary solutions can be integrated, and the implementation guide is not exhaustive. You must review, evaluate, assess and approve the solution in compliance with your organization's particular security features, tools and configurations. It is the sole responsibility of you and your organization to determine which regulatory requirements are applicable and to ensure that you comply with all requirements. And although the solution discusses both the technical and the administrative requirements, it does not help you comply with the non-technical administrative requirements. That last sentence is the one to hold on to. A landing zone accelerator can give you the accounts, the logging, the detective controls and the network inspection, and it cannot give you the evidence that your staff followed a procedure, the training, the policies, or the sign-off. Compliance is a process that runs alongside the infrastructure, not a property the infrastructure has. This is why the tester package matters. Creating AWS Config custom rules for every test case in the manifest turns the accelerator's own expectations into continuous checks, which is a technical control against a specific configuration, and it is still not an audit of your organisation. The same paragraph also tells you what to do with the solution. It is a starting point that you assess and approve, not a compliance product you adopt, and any evaluation should start from that framing rather than from the feature list. ## Documentation, branches and how releases are cut The documentation is split across two places, and the README tells you which is which. The Implementation Guide is on the AWS documentation site and covers deployment, customization and maintenance, while the additional documentation for the solution is hosted on GitHub Pages at awslabs.github.io/landing-zone-accelerator-on-aws, and the README strongly recommends reviewing that resource as well as the guide. The repository listing shows how much of the project is build and release machinery. There is a buildspec.yml, a .gitlab-ci.yml alongside a .gitlab directory and the .github directory, sonar-project.properties for static analysis, codescan-prebuild-custom.sh and codescan-postbuild-custom.sh for the code scanning steps, a container directory, and a .viperlightrc with .viperlightignore for the documentation tooling. A GitLab pipeline in a GitHub-hosted repository is unusual, and it is the kind of detail that tells you the project is built by more than one organisation's release process. The release model is visible in the branch names. The default branch is release/v1.16.3, and the recent tags are v1.16.1, v1.16.2 and v1.16.3, so a version maps to a branch and a tag. For an adopter this means the version you read about is the version you pin, and the CHANGELOG.md at the root is where to see what changed between them. The documentation structure also implies a division of audience. The GitHub Pages site is the reference for the accelerator itself, the implementation guide is the deployment path, and the FAQ and DEVELOPING documents in the repository are for the two questions that come up first, what does this do, and how do I work on it. ## Conclusion Adopt the Landing Zone Accelerator when you are building an AWS landing zone for regulated workloads, you already run AWS Control Tower, and you want the configuration and the resulting infrastructure as code in your own repository rather than as console clicks. Do not adopt it as a compliance product, because the README states plainly that it will not by itself make you compliant and that non-technical administrative requirements are out of scope. Before you deploy, read the Implementation Guide and the GitHub Pages documentation rather than the README, check the release branch you are pinning, since the default branch is release/v1.16.3, and decide whether you want the solution's own operational metrics collection enabled before you start. ## FAQ ### What is the Landing Zone Accelerator on AWS? It is an open source AWS CDK project that deploys a multi-account cloud foundation to support highly regulated workloads and complex compliance requirements, designed to sit alongside AWS Control Tower, which the README recommends deploying first as the foundational landing zone. ### Does the Landing Zone Accelerator make an organisation compliant? No, and the README says so directly. The solution will not by itself make you compliant, it provides foundational infrastructure for complementary solutions, and you must review, evaluate, assess and approve it. It also does not help with the non-technical administrative requirements of compliance. ### Which packages make up the Landing Zone Accelerator? The @aws-accelerator/accelerator CDK application with the stack definitions and deployment pipelines, @aws-accelerator/config for the configuration files, @aws-accelerator/constructs, @aws-accelerator/installer, @aws-accelerator/utils, a future @aws-accelerator/ui, plus @aws-cdk-extensions/cdk-extensions and the @aws-cdk-extensions/tester app that creates AWS Config custom rules from the test case manifest. ### Does using the Landing Zone Accelerator on AWS cost anything extra? No additional charges or upfront commitments are required. You pay only for the AWS services enabled to set up the platform and operate your controls, and the solution can also support non-standard partitions including AWS GovCloud (US) and the US Secret and Top Secret regions. ## Sources - [awslabs/landing-zone-accelerator-on-aws on GitHub](https://github.com/awslabs/landing-zone-accelerator-on-aws) - [License: Apache-2.0](https://github.com/awslabs/landing-zone-accelerator-on-aws/blob/release/v1.16.3/LICENSE) - [Project website](https://aws.amazon.com/solutions/implementations/landing-zone-accelerator-on-aws/) - [README](https://github.com/awslabs/landing-zone-accelerator-on-aws/blob/release/v1.16.3/README.md) - [Releases](https://github.com/awslabs/landing-zone-accelerator-on-aws/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/awslabs-landing-zone-accelerator-on-aws