Releases: awslabs/landing-zone-accelerator-on-aws
v1.14.2
Important
We highly recommend that you keep your environments up to date by upgrading to the latest version. See Update the solution for the required actions to upgrade.
New Features
Enhanced Transit Gateway Attachment Processing
The LZA now includes batch lookup functionality for Transit Gateway attachment IDs in the Network Associations stack, replacing individual attachment lookup custom resources with optimized batched operations that can handle up to 90 attachments per custom resource. This change will allow for more CloudFormation resources to be deployed in the Network Associations stack.
During the upgrade process, customers will observe the deletion of existing Custom::GetTransitGatewayAttachment custom resources. This is expected behavior as the solution transitions from individual lookup resources to the new batched implementation. No configuration file changes are required, as this optimization occurs automatically during the deployment process.
The LZA team highly recommends utilizing stack policies to protect critical CloudFormation resources deployed by the LZA.
Enhanced TypeDoc Documentation
This release includes comprehensive improvements to TypeDoc documentation. The documentation has been enriched with further detail and reorganized to highlight the 8 top-level interfaces that align with files in the LZA configuration repository. These changes are designed to make it easier for users to identify existing features supported by the LZA.
Bug Fixes
AWS Control Tower Integration
This fix prevents deployment failures when certain Control Tower Landing Zone configuration properties are not explicitly defined, providing more robust handling of Control Tower operations.
Prerequisites Account Management
LZA now properly handles suspended accounts within ignored Organizational Units during the prerequisites phase. Previously, the solution would attempt to process suspended accounts, leading to deployment failures. The updated logic correctly identifies and skips these accounts.
Session Manager Logging
We've resolved permissions issues affecting Session Manager log group creation and management. The fix ensures that proper IAM permissions are applied to Session Manager log groups, allowing for consistent logging functionality across all managed accounts.
ASEA Transit Gateway Route Handling
ASEA handlers now includes improved error handling for Transit Gateway route lookups.
Container Module Deployment
Fixed an issue where the accelerator stage was not properly added during the prepare stage for modules in container deployments. This resolution ensures that all necessary deployment stages are executed in the correct sequence, preventing module deployment failures.
Documentation Links
Corrected broken links throughout the user guide documentation, ensuring that all references point to the correct resources and improving the overall user experience when navigating the documentation.
GuardDuty Detector Features
We have resolved an issue that resulted in newly provisioned AWS accounts having only a subset of features such as S3 Protection and EKS Protection enabled on their GuardDuty detector. In order to ensure new accounts are automatically registered with GuardDuty, ensure the autoEnableOrgMembers property is set to true.
Additional Resources
For full details, please see the CHANGELOG.
v1.14.1
Important
We highly recommend that you keep your environments up to date by upgrading to the latest version. See Update the solution for the required actions to upgrade.
Fixed
- fix(budgets): remove trailing slash in path
- fix(controltower): allow retry of failed install, update sdk
- fix(networking): added lookup for tgw attachments using v2 stacks in govcloud
- fix(typedocs): updated basePath for compatibility with latest version
Please see the v1.14.0 Release Notes for information on significant changes from a previous minor version.
v1.14.0
Important
We highly recommend that you keep your environments up to date by upgrading to the latest version. See Update the solution for the required actions to upgrade.
CRITICAL
If you're on an LZA installation that is a non-standard AWS partition (e.g. AWS GovCloud (US)), please do not upgrade to 1.14.0 until a 1.14.1 release is made available. Please see this issue
New Features
Split Large Files with YAML !include directive
The LZA now supports the !include directive in configuration files to modularize and organize complex configurations. This feature allows you to split large configuration files into smaller, more manageable files and include them using relative paths. For more information, please see this page.
IPv6 VPN Connectivity
Expanded networking capabilities now include IPv6 support for VPN connections, providing organizations with modern networking options and enhanced connectivity for IPv6-enabled environments. This feature supports the growing adoption of IPv6 infrastructure while maintaining backward compatibility with existing IPv4 configurations.
CDK Toolkit Upgrade
This release includes an update to the version of the AWS CDK used by the LZA which required updates to the LZA engine's role assumption process for AWS API actions, CDK synthesis, and deployments. Previously, a single customer-specified role handled CDK deployment and synthesis. The new CDK implementation requires a two-step role assumption: first assuming the customer-specified role, then assuming the CDK bootstrap role from the CDK-Toolkit template.
To accommodate this change, we've introduced two new roles. The first is a Bootstrap role in the AWS-CDKToolkit, protected by SCPs and following LZA best practices. This role is only assumable by the management account for CDK deployments. The second is an LZA management role in the management account, responsible for CDK-specific actions on the management account only.
These architectural changes enhance our security posture by providing more granular control over the deployment process and IAM policies. This approach reduces dependency on service roles like AWSControlTowerExecution and allows for greater flexibility in future implementations. For more information, the CDK role assumption change is documented in GitHub Issue #25185.
Uninstaller Local Configuration Support
The LZA Uninstaller now supports the usage of a local configuration directory during uninstallation, simplifying the process for customers automating the creation and cleanup of Landing Zone Accelerator resources.
Bug Fixes
AWS Control Tower
In this release, we've resolved several critical AWS Control Tower integration issues. We've fixed permissions issues that were causing landing zone operations to fail when working with Customer Managed Keys (CMK). The OU registration process has been improved to handle BadRequestException errors gracefully, and we've enhanced operation handling to ensure manifest properties remain unchanged without a corresponding change to the LZA configuration.
SSM Document Configuration Preservation
LZA now preserves existing SSM document settings for runAsEnabled and runAsDefaultUser when updating SSM documents, preventing the solution from overriding customer-configured permissions. This enhancement allows customers to maintain their custom SSM Run As user configurations without interference from LZA pipeline runs.
SCP Detachment Behavior
LZA has updated the service control policy (SCP) detachment logic to fix a bug that could detach more SCP policies than intended. When modifying the configuration file to detach a specific SCP from an Organizational Unit (OU), the LZA may detach additional LZA-managed SCPs from that OU. This is resolved during the next run of the LZA pipeline.
Changes
CDK and SDK Updates
The LZA v1.14.0 includes upgrading the version of the AWS CDK to v2.219.0 and leveraging the AWS CDK Toolkit Library. This update ensures availability of the latest AWS services and features and enabled the LZA to migrate all AWS API interactions to the AWS JS SDK V3, removing the dependency on the AWS JS SDK V2.
CDK Bootstrap ECR Repository
In previous versions of LZA, an Amazon Elastic Container Registry (ECR) repository was automatically created to store docker images used by AWS CDK. While this repository was not used by the LZA, it was included to maintain parity with the typical CDK bootstrapping process and expected resulting resources.
In v1.14.0, the LZA has removed this ECR repository from the bootstrap template. You may still see retained ECR repositories after the update because of the deletion policy specified in the default CDK bootstrap template. These repositories can be manually deleted if desired without impacting LZA operations.
LZA Universal Configuration
The LZA team has released the LZA Universal Configuration which consolidates multiple configuration variants into a unified, modular framework. We have removed sample configurations from this repository and encourage users to reference the LZA Universal Configuration moving forward.
Contributors
We want to extend a special thank the the following external users that have contributed to this release:
Additional Resources
For full details, please see the CHANGELOG.
Contributors
Assets 2
v1.13.1
Important
We highly recommend that you keep your environments up to date by upgrading to the latest version. See Update the solution for the required actions to upgrade.
Fixed
- fix(asea): fix lambda role replacement for asea functions
- fix(asea): remove deprecated asea phase5 lambdas
- fix(config-service): create service linked role when orgs only #834 #857
- fix(macie): allow undefined value for excluded regions
- fix(metadata): missing s3 read permissions on accelerator metadata lambda role #864
- fix(networking): fix rql resource from being recreated
- fix(networking): reverts bug disabling private dns for vpc interface endpoints
- fix(organizations): don't add existing accounts to org account creation
- fix(pipeline): add missing environment variable for validation
- fix(stack-policy): fix error on new account creation
- fix(validation): added partition env var to pipeline
- fix(validation): add validation for imported access log bucket name
Changed
- chore(configs): update sample configurations to lza universal config
- chore(control-tower): updated default access logs retention to 365 days
- chore(docs): add v2 mkdoc navigation
- chore(docs): update service quota documentation
- chore(docs): update documentation for maxPasswordAge
- chore(docs): update security hub findings and universal configuration reference
- chore(logging): updated default cloudwatch log retention to 1 year
- Revert "fix(validation): query log without r53 resolver configured" #876
NEW: LZA Universal Configuration
The LZA team has released the LZA Universal Configuration which consolidates multiple configuration variants into a unified, modular framework. We have removed sample configurations from this repository and encourage users to reference the LZA Universal Configuration moving forward.
v1.13.0
Important
We highly recommend that you keep your environments up to date by upgrading to the latest version. See Update the solution for the required actions to upgrade.
Breaking Changes
For users who previously utilized the ACCELERATOR_NO_ORG_MODULE environment variable in the AWSAccelerator-ToolkitProject CodeBuild project to address AWS Control Tower API errors during organizational unit registration, please note the following changes after upgrading to LZA v1.13.0:
- Remove the ACCELERATOR_NO_ORG_MODULE variable.
- Add four new environment variables to the AWSAccelerator-ToolkitProject:
- SkipCreateOrganizationalUnit
- SkipRegisterOrganizationalUnit
- SkipInviteAccountsToOrganizations
- SkipMoveAccounts - Set each of these new variables to "yes" to maintain functionality similar to the previous ACCELERATOR_NO_ORG_MODULE setting.
These changes provide more granular control over specific organizational actions while addressing the same API error concerns.
New Features
Network Refactor
A major architectural enhancement in LZA v1.13.0 transforms how network resources are deployed, significantly improving scalability for customers with complex networking needs. Previously constrained by CloudFormation's 500-resource limit per stack, the LZA now deploys each VPC in its own independent stack, eliminating restrictions on the number of VPCs that can be deployed within an AWS account and region. To enable V2 stacks, please review the documentation here.
CloudFormation Stack Policies
The LZA introduces support for CloudFormation Stack Policies, enabling organizations to prevent unintentional updates or deletions of critical stack resources during CloudFormation stack updates. This new capability allows for granular configuration of protected resource types within LZA-created stacks, helping organizations maintain infrastructure stability while retaining flexibility for controlled updates when needed.
RCPs and Declarative policies
The LZA has expanded its policy management capabilities by adding support for both Resource Control Policies (RCPs) and Declarative Policies. RCPs help establish data perimeters by restricting external access to resources at scale, while Declarative Policies enable you to enforce desired service configurations across your organization - such as ensuring EC2 instances only launch from approved AMIs or automatically blocking public VPC access. Both policy types are enforced centrally within Organizations, providing central governance and security teams with robust preventive controls that maintain compliance with organizational standards, even as services evolve with new features and APIs.
Performance Improvements
-
This release introduces significant performance enhancements through caching. By caching the code built by the installer pipeline, we've eliminated the need for redundant build steps in the core pipeline, reducing execution time by approximately 6 minutes per run.
-
Additionally, we've optimized CloudFormation updates by changing the default behavior to perform direct updates rather than creating change sets. This modification results in approximately 15% faster pipeline execution times, with more significant improvement in large environments. Change sets can still be enabled if preferred.
Contributors
Thank you to the following open-source contributors with features included in this release:
Full Changelog: release/v1.12.0...release/v1.13.0
Contributors
Assets 2
v1.12.6
Important
We highly recommend that you keep your environments up to date by upgrading to the latest version. See Update the solution for the required actions to upgrade.
Fixed
- fix(asea): create tgw association asea resource without propagation
- fix(asea): fix tgw route lookup with vpc name
- fix(asea): lookup vpc endpoints using asea names and vpc
- fix(asea): remove underscores from logical id lookup
v1.13.0-experimental-a
Important Notice: Experimental Release v1.13.0
We are pleased to announce an experimental release of the Landing Zone Accelerator on AWS, providing early access to upcoming features and improvements.
Intended Usage and Environment Considerations
This experimental release is specifically designed for evaluation and testing purposes in development environments only. Given the nature of pre-release software and ongoing refinements, we strongly advise against deploying these features in production environments at this time. Organizations should continue to rely on our latest official release for production workloads to ensure maximum stability and support coverage.
Support and Issue Reporting Guidelines
Any issues encountered while using this experimental release should be reported directly through our GitHub issues, rather than through AWS Support directly. This approach allows our development team to rapidly address feedback and incorporate improvements into the upcoming official release. When submitting GitHub issues, please clearly indicate that it relates to the experimental release (experimental/v1.13.0) to help us properly track and address your input.
Path to Official Release
Features and improvements introduced in this experimental release will undergo thorough testing and refinement before being incorporated into an official release. We encourage users to subscribe to our repository notifications to stay informed about updates and the timeline for official release availability.# Release Notes - Version 1.13.0
Breaking Changes
For users who previously utilized the ACCELERATOR_NO_ORG_MODULE environment variable in the AWSAccelerator-ToolkitProject CodeBuild project to address AWS Control Tower API errors during organizational unit registration, please note the following changes after upgrading to LZA v1.13.0:
- Remove the
ACCELERATOR_NO_ORG_MODULEvariable. - Add four new environment variables to the AWSAccelerator-ToolkitProject:
-SkipCreateOrganizationalUnit
-SkipRegisterOrganizationalUnit
-SkipInviteAccountsToOrganizations
-SkipMoveAccounts - Set each of these new variables to "yes" to maintain functionality similar to the previous
ACCELERATOR_NO_ORG_MODULEsetting.
These changes provide more granular control over specific organizational actions while addressing the same API error concerns.
New Features
Network Refactor
A major architectural enhancement in LZA v1.13.0 transforms how network resources are deployed, significantly improving scalability for customers with complex networking needs. Previously constrained by CloudFormation's 500-resource limit per stack, the LZA now deploys each VPC in its own independent stack, eliminating restrictions on the number of VPCs that can be deployed within an AWS account and region. For more information, please see here.
CloudFormation Stack Policies
The LZA introduces support for CloudFormation Stack Policies, enabling organizations to prevent unintentional updates or deletions of critical stack resources during CloudFormation stack updates. This new capability allows for granular configuration of protected resource types within LZA-created stacks, helping organizations maintain infrastructure stability while retaining flexibility for controlled updates when needed.
RCPs and Declarative policies
The LZA has expanded its policy management capabilities by adding support for both Resource Control Policies (RCPs) and Declarative Policies. RCPs help establish data perimeters by restricting external access to resources at scale, while Declarative Policies enable you to enforce desired service configurations across your organization - such as ensuring EC2 instances only launch from approved AMIs or automatically blocking public VPC access. Both policy types are enforced centrally within Organizations, providing central governance and security teams with robust preventive controls that maintain compliance with organizational standards, even as services evolve with new features and APIs.
Performance Improvements
-
This release introduces significant performance enhancements through caching. By caching the code built by the installer pipeline, we've eliminated the need for redundant build steps in the core pipeline, reducing execution time by approximately 6 minutes per run.
-
Additionally, we've optimized CloudFormation updates by changing the default behavior to perform direct updates rather than creating change sets. This modification results in approximately 15% faster pipeline execution times, with more significant improvement in large environments. Change sets can still be enabled if preferred.
Full Changelog: v1.12.0...v1.13.0-experimental-a
v1.12.5
Important
We highly recommend that you keep your environments up to date by upgrading to the latest version. See Update the solution for the required actions to upgrade.
Fixed
- fix(kms): fix policy condition error
Changed
- chore: fixed CVE-2025-7783 via yarn resolution for form-data
v1.12.4
Important
We highly recommend that you keep your environments up to date by upgrading to the latest version. See Update the solution for the required actions to upgrade.
Fixed
- fix(asea): lookup tgw attachments using asea vpc names
- fix(logging): add permissions to cloudwatch log creation for kms association
- fix(networking): remove duplicates for gateway loadbalancer endpoints
v1.12.3
Important
We highly recommend that you keep your environments up to date by upgrading to the latest version. See Update the solution for the required actions to upgrade.
Skip Bulk Updates For CloudWatch Logs
In LZA environments containing more than 5,000 CloudWatch Log Groups, some users observed the Custom::UpdateSubscriptionFilter function times out during upgrades when attempting to take action on every log group. In order to provide a path forward for these customers, the LZA added a configuration option that can be used to skip bulk updates in these instances. Please note that enabling this configuration option can cause the targeted environments to become out of sync from the configuration specified for CloudWatch Log Groups in the global configuration. For new LZA deployments after v1.12.0, we recommend customers use account level subscription filters to solve this problem.
Added
- feat(control-tower): allow expanded set of ct control identifiers
Fixed
- fix(asea): udp security group ingress rule using incorrect port definition
- fix(cloudwatch): added skip bulk updates for custom resource
- fix(sample-config): removed dash to extend preventative measures to roles
- fix(sqs): add cfn nag rules
- fix(ssm): analyze account input in share document