Release Notes v1.17.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. The Landing Zone Accelerator on AWS is designed and tested to work with the latest versions of Service Control Policies (SCPs) from the LZA Universal Configuration and the LZA CCCS Medium Configuration. Please review the latest changes in these repositories to ensure your SCPs align with the latest changes.

Review the following before you upgrade. Each item is described in more detail under New Features or Changes.

Installer parameter removed: The EnableDiagnosticsPack installer parameter is removed. If your deployment automation passes it to the installer stack, remove it before you upgrade. After the upgrade, delete the termination-protected DiagnosticsPackStack in the pipeline account manually.
Amazon Macie automated discovery: If you run v1.16.x and did not set automatedDiscoveryEnabled, the first pipeline run after the upgrade turns Macie automated sensitive data discovery off. Set centralSecurityServices.macie.automatedDiscoveryEnabled: true to keep it on.
AWS GovCloud (US) log group encryption: In the aws-us-gov partition, existing CloudWatch Logs log groups are updated in place to use the configured CMK. Before you upgrade, grant permissions on the CMK to any principal outside LZA that reads or writes these log groups.
Tag and backup policies: Accounts listed under deploymentTargets.accounts for tag policies or backup policies were ignored before v1.17.0. The first run after the upgrade attaches those policies to those accounts.
Cross-zone load balancing: Gateway and Network Load Balancers configured with crossZoneLoadBalancing: false have been running with cross-zone load balancing turned on. The first run after the upgrade turns it off. Confirm that targets or appliances are registered in every enabled Availability Zone first.
Security Hub automation rules: A rule that the AWS Security Hub API rejects now fails the pipeline. Earlier versions logged the error and continued.
Manually created endpoint DNS records: If you created the wildcard record *.dkr.ecr-fips.<region>.amazonaws.com or *.gateway.bedrock-agentcore.<region>.amazonaws.com yourself in the private hosted zone that LZA creates for a centralized interface endpoint, delete it before you upgrade. LZA now creates these records, and the NetworkVpcDns stack update fails if the record already exists.
DNS Firewall associations with mutation protection: Any tag change on a DNS Firewall rule group association with mutationProtection: ENABLED fails the NetworkAssociations stack. The upgrade changes the tag on such an association when the association and global-config.yaml set the same tag key. Use the two-run procedure under Tags on Mutation-Protected DNS Firewall Associations.
Resource policy compliance with SourceAccount: If resourcePolicyEnforcement is enabled and a policy set has the SourceAccount input parameter, the compliance check now flags non-mandated Allow statements that grant access outside the allowlist on every supported resource type. Earlier versions applied SourceAccount only to Lambda functions and Certificate Authority resources. Review cross-account Allow statements before you upgrade, because a flagged resource stays NON_COMPLIANT until you remove the statement.

New Features

Amazon GuardDuty module

LZA now manages Amazon GuardDuty through an SDK-based module instead of CloudFormation custom resources, following the module pattern that Amazon Macie moved to in v1.16.0. You continue to configure GuardDuty under centralSecurityServices.guardduty in security-config.yaml, which gains the following options and behaviors:

disabledRegions turns GuardDuty off in the listed Regions by deleting the detector in each account, including the delegated administrator and management accounts. It defaults to an empty list and should not overlap excludeRegions.
overrideExisting: true makes the module apply the configuration on the next run even when the configuration has not changed since the last successful run. Set it, run the pipeline, and then remove it.
eksProtection.auditLogs and eksProtection.runtimeMonitoring control EKS Audit Log Monitoring and EKS Runtime Monitoring separately, so you can turn on audit logs in Regions where runtime monitoring is not available. The existing eksProtection.enable flag still turns on both features and cannot be combined with the new flags. EKS Runtime Monitoring is billed per vCPU. In Regions that do not support runtime monitoring, such as us-iso-east-1, omit runtimeMonitoring rather than setting it to false.
When Malware Protection for EC2 is enabled in at least one Region, the module enables AWS Organizations trusted access for malware-protection.guardduty.amazonaws.com from the management account.
The management account and the delegated administrator (Audit) account are added automatically when deploymentTargets omits them.
In a Region or partition that rejects the requested GuardDuty feature names, the module logs a warning and retries with S3 protection only.
Member enrollment can take longer in slower partitions or large organizations. Set the GUARDDUTY_OPERATION_TIMEOUT pipeline environment variable (milliseconds, default 900000) to allow more time. MACIE_OPERATION_TIMEOUT (default 300000) does the same for the Macie module.

Upgrade note: The first run after the upgrade sets the existing GuardDuty custom resources to DeletionPolicy: Retain and removes them from the stack templates, and the module then applies your GuardDuty configuration. The retained Lambda functions and log groups are left in place. Protection plans that you do not configure (EC2 malware protection, RDS, Lambda) are still set to disabled, as in earlier versions. To keep the custom resource behavior from v1.16.x, set the SKIP_GUARDDUTY_MODULE=true environment variable on the accelerator pipeline.

Configuration validation mode

A new configurationValidationMode setting in global-config.yaml controls how LZA handles keys that are not part of the configuration schema, which usually come from typos or properties placed at the wrong level. With off (the default), LZA ignores them. With warn, it logs a warning for each one. With strict, it fails the pipeline and suggests the key you most likely meant. The check covers the accounts, customizations, global, IAM, network, organization, replacements, and security configuration files. We recommend running with warn before you switch to strict.

Block public access to AMIs

centralSecurityServices.blockPublicAmi in security-config.yaml turns on EC2 image block public access in every LZA-managed account and enabled Region, which prevents AMIs from being shared publicly. Accounts listed in excludeAccounts have block public access turned off. Setting enable: false turns it off in every account, including settings made outside LZA, so leave the block out of your configuration if you do not want LZA to manage this setting.

Transit Gateway encryption support

Transit gateways in network-config.yaml accept a new encryptionSupport property (enable or disable, default disable) that turns on support for VPC Encryption Controls. Traffic between attached VPCs that have Encryption Controls enabled then travels over encrypted lanes. All attached VPCs must be in the same Region, and Encryption Controls charges apply to each attached VPC. Configuration validation rejects encryptionSupport when it is combined with security group referencing, multicast, Transit Gateway Connect attachments, or peering attachments. Changing this property on an existing transit gateway does not replace the transit gateway.

AWS Config Custom Policy rules

AWS Config rules in security-config.yaml now support type: CustomPolicy for Guard-based custom policy rules. Provide the Guard rule in customPolicyRule.policyText, either inline or as the path to a file in your configuration repository. Policy text is limited to 10,000 characters. Optional fields include customPolicyRule.enableDebugLog, complianceResourceTypes, and inputParameters.

- name: dynamodb-pitr
  type: CustomPolicy
  customPolicyRule:
    policyText: custom-config-rules/my-guard-rule.guard

Tags on AWS Config rules

AWS Config rules now receive the global tags from global-config.yaml and the Accelerator tag, in addition to the tags defined on the rule itself. Tag values can use plaintext {{resolve:ssm:...}} references. Tags that use ssm-secure or AWS Secrets Manager references are skipped.

Modules section in the diff viewer

The HTML diff viewer now includes a Modules section that shows module runner dry-run output, so the changes that modules will make appear next to the CloudFormation changes during the Review stage. Modules with no pending changes are marked as having no changes. Module changes are compared against live AWS state at the time of the diff.

Concurrent execution guard

Set acceleratorSettings.failOnConcurrentExecution: true in global-config.yaml to stop a deployment when a newer pipeline execution has replaced the configuration snapshot that the deployment started with. This prevents a superseded execution from deploying with account data written by the newer execution. The setting defaults to false.

Account-level IAM Access Analyzer

accessAnalyzer.accountAnalyzer in security-config.yaml creates an account-level external access analyzer in every account and enabled Region, which helps satisfy AWS Security Hub control IAM.28. It requires accessAnalyzer.enable: true. Use accountAnalyzer.deploymentTargets to limit where the analyzers are created. The AWS Config rule behind IAM.28 is not available in the AWS GovCloud (US) Regions, the China Regions, or Canada West (Calgary). Creating the analyzers also creates the AWSServiceRoleForAccessAnalyzer service-linked role in each account, and LZA does not remove that role when you turn the option off.

Upgrade note: An account can have only one account-level external access analyzer per Region. Delete any existing analyzer of this type before you enable the option, or the stack update rolls back. Exclude Regions in the aws-iso and aws-iso-b partitions. Expect additional findings in every account where the analyzer is created.

Resource policy tamper detection

The resource policy compliance check in resourcePolicyEnforcement now flags tampered resource policies for Amazon S3, AWS KMS, IAM trust policies, AWS Secrets Manager, Amazon ECR, Amazon SNS, Amazon SQS, Amazon OpenSearch Service, Amazon EventBridge, Amazon EFS, AWS Backup vaults, AWS CodeArtifact, and Amazon API Gateway. Duplicate statement IDs and drift from the mandated baseline are always detected. When you set the SourceAccount input parameter on a policy set, the check also flags Allow statements that grant access to principals outside that allowlist. This is detection only, and remediation never removes a statement. Expect new NON_COMPLIANT findings where policies were changed outside LZA.

Upgrade note: This affects deployments with resourcePolicyEnforcement.enable: true where a policy set sets inputParameters.SourceAccount. In v1.16.x, SourceAccount applied only to Lambda functions and Certificate Authority resources, and for the other resource types the check verified only that the mandated statements were present and unmodified. In v1.17.0, SourceAccount also turns on the statement check for the resource types listed above, with no configuration change. A non-mandated Allow statement is not flagged when:

every account it references is in SourceAccount or is the resource's own account
it is scoped to your organization with aws:PrincipalOrgID, aws:PrincipalOrgPaths, aws:SourceOrgID, or aws:SourceOrgPaths
its wildcard principal is narrowed to allowlisted accounts with aws:SourceArn, aws:SourceAccount, or aws:SourceOwner
it names only a service principal
SourceAccount is set to ALL

A statement that references another account, uses a wildcard principal without such a condition, or uses NotPrincipal is flagged. Deny statements are never flagged, and a negated condition operator such as StringNotEquals does not count as scoping. Before you upgrade, review non-mandated Allow statements that grant cross-account access, and add the account to SourceAccount, scope the statement with aws:PrincipalOrgID, or plan to remove it.

Because remediation never removes a statement, a flagged resource stays NON_COMPLIANT until you remove the statement yourself. Automatic remediation reports success while leaving the statement in place. This is expected.

Session Manager document settings

logging.sessionManager in global-config.yaml accepts four optional settings, which LZA writes to the Session Manager preferences document only when you set them:

idleSessionTimeout: 1 to 60 minutes
maxSessionDuration: 1 to 1440 minutes
cloudWatchStreamingEnabled: requires sendToCloudWatchLogs
shellProfile: linux, windows, or both

LZA writes these settings from the configuration whenever it updates the document. A value changed outside LZA is overwritten at that point, and a setting you remove from the configuration returns to the Session Manager default. Commands in shellProfile run at the start of every session on the managed nodes in the accounts and Regions where LZA manages the document.

Account tags

Accounts in accounts-config.yaml accept an optional tags list, which LZA applies to the account through AWS Organizations. LZA only adds tags and updates changed values. Removing a tag from the configuration does not remove it from the account, and tags added outside LZA are left in place. An account can have at most 50 tags, including tags added outside LZA. Keys must be 1 to 128 characters and must not start with aws:, and values can be up to 256 characters.

Tag and backup policies on directly targeted accounts

Tag policies and backup policies in organization-config.yaml now attach to accounts listed under deploymentTargets.accounts, and excludedAccounts is honored. Earlier versions attached these policies only to organizational units. A module manages the account attachments. It removes an attachment only if LZA created it and the account was later removed from or excluded in the configuration, and it leaves attachments made outside LZA in place.

Upgrade note: If your configuration already lists accounts for these policies, the first run after the upgrade attaches the policies to those accounts. An account can have at most 10 directly attached policies of each type, and configuration validation rejects a configuration that attaches more.

Customization stack parameter types

Parameters of customization CloudFormation stacks (customizations.cloudFormationStacks[].parameters[]) accept an optional type of String, Number, List<Number>, or CommaDelimitedList, so number and list values are passed to the template as the declared type. The default is String.

Auto Scaling group names

The autoscaling settings of EC2 firewall Auto Scaling groups and of applications in customizations-config.yaml accept an optional autoScalingGroupName that sets the physical name of the Auto Scaling group. When you leave it out, CloudFormation generates the name, as in earlier versions. The existing name field identifies the group inside the configuration and is not used as its name in AWS.

Caution: Setting or changing autoScalingGroupName on an existing Auto Scaling group, including setting it for the first time, replaces the group. The existing instances are terminated and the group is recreated, which can interrupt running workloads.

Container installer network IDs in SSM

The container installer now publishes the VPC, subnet, and security group IDs of its ECS task to SSM parameters under /<prefix>/<stackName>/network/ (vpc/id, subnet/id, and security-group/id). With an external pipeline account, the path also includes the qualifier. The values are the resources that the installer created, or the IDs that you provided when UseExistingVpc is Yes.

Changes

Node.js 24

The solution runtime has been upgraded to Node.js 24, and the minimum supported Node.js version is now 22. If you override the Node.js version with the installer's AcceleratorNodeVersion parameter, set it to 22 or later.

Diagnostics Pack Removal

The installer-deployed Diagnostics Pack (its stack, per-account access role, and report Lambda function) has been removed, because pipeline failure diagnostics are collected automatically. The EnableDiagnosticsPack installer parameter is removed, so drop it from any automation that passes it before you upgrade. The per-account DiagnosticsPackAccessRole is deleted on the next pipeline run. The DiagnosticsPackStack in the pipeline account is termination protected and must be deleted manually, as described in the troubleshooting guide.

Amazon Macie Automated Discovery Default

automatedDiscoveryEnabled for Amazon Macie now defaults to false, which makes automated sensitive data discovery opt-in. In v1.16.x the Macie module turned it on when the field was unset, so deployments that relied on that default have automated discovery turned off on the first pipeline run after the upgrade. Set centralSecurityServices.macie.automatedDiscoveryEnabled: true to keep it on. The setting is also required when classificationScopeExcludedBuckets is set. Releases before v1.16.0 never enabled automated discovery.

CloudWatch Logs Encryption in AWS GovCloud (US)

In the aws-us-gov partition, LZA no longer removes KmsKeyId and Tags from CloudWatch Logs log groups, so the configured CMK is applied. On upgrade, existing log groups are updated in place to use the CMK and the accelerator tags. Log groups that were not encrypted with the CMK start encrypting new log data with it, and data that was already ingested is unchanged.

Upgrade note: Before you upgrade, grant permissions on the CMK to any principal outside LZA that reads or writes these log groups.

Flow Log Format and Tags in ISO Partitions

In the aws-iso and aws-iso-b partitions, custom LogFormat settings and tags on VPC flow logs and Transit Gateway flow logs are now applied. Earlier versions removed them, so flow logs used the default 14-field format. MaxAggregationInterval is still not supported in these partitions, so flow logs keep the 600-second default aggregation interval.

Upgrade note: If you configured a custom format, the first run after the upgrade replaces the affected flow logs. The log group is retained, and no log data is lost.

Cross-Zone Load Balancing for Gateway and Network Load Balancers

crossZoneLoadBalancing: false is now honored for Gateway Load Balancers and Network Load Balancers. Earlier versions always rendered the attribute as true, so a load balancer configured with false is currently running with cross-zone load balancing turned on.

Upgrade note: The first run after the upgrade turns cross-zone load balancing off in place, without replacing the load balancer. Before you upgrade, confirm that targets or appliances are registered in every enabled Availability Zone, so that an Availability Zone without a healthy target does not drop traffic.

Global Tag Precedence

Tags from global-config.yaml are now applied as defaults. A tag with the same key set on a resource, for example on a VPC or a route table, takes precedence over the global tag.

Upgrade note: Where a resource and global-config.yaml set the same tag key, the first run after the upgrade changes that tag on the resource to the resource-level value.

Tags on Mutation-Protected DNS Firewall Associations

CloudFormation cannot modify a Route 53 Resolver DNS Firewall rule group association that has mutationProtection: ENABLED. Tags are accepted when the association is created, but any later change to them is rejected and fails the NetworkAssociations stack. This applies to global tags from global-config.yaml and to tags set on the association under dnsFirewallRuleGroups in network-config.yaml. Because of the tag precedence change above, the first run after the upgrade changes the tag on any association that sets the same key as a global tag.

To change tags on protected associations, use two pipeline runs:

Run 1: Make the tag change, and set mutationProtection: DISABLED on the affected associations. Run the pipeline.
Run 2: Set mutationProtection: ENABLED on those associations again, and leave the tags as they are. Run the pipeline.

A run that changes tags must turn protection off in that same run. Otherwise CloudFormation attempts the change while the association is still protected, and the service rejects it. If the upgrade changes tags on a protected association, set mutationProtection: DISABLED before you upgrade and treat the upgrade as Run 1. If a tag change runs while protection is on, the stack update fails with InvalidRequest and rolls back without manual recovery, and you can start again with Run 1. Associations without mutation protection accept tag changes normally, and tags applied outside LZA are not removed.

STS Endpoint Resolution

LZA no longer hardcodes the AWS STS endpoint in the pipeline and CLI execution environment or in the @aws-lza modules. The AWS SDK now resolves the Regional endpoint and honors AWS_ENDPOINT_URL_STS, AWS_ENDPOINT_URL, and AWS_USE_FIPS_ENDPOINT where they are set. STS clients inside Lambda-backed custom resources do not receive these variables. This resolves #1183.

Customization Lambda Environment Variables

LZA no longer adds the SOLUTION_ID environment variable to Lambda functions defined in your customization CloudFormation templates, which broke Lambda@Edge functions. This resolves #643.

Service Catalog Association Propagation

propagateAssociation: true on a portfolio association in customizations-config.yaml now creates the association in every account the portfolio is shared with. Earlier versions could not assume the cross-account role used for propagation, so these associations were not created, and the deployment did not report the failure. The execution role of the propagation function is now named <prefix>-ServiceCatalogPropagationRole-<region>, which the cross-account role's trust policy accepts.

Upgrade note: The first run after the upgrade creates the propagated associations, so principals with the configured names in the shared accounts get access to the portfolio. Because propagation matches principals by name, a user who can create IAM principals in a shared account could give themselves access by creating one with a matching name. If that is a concern, set propagateAssociation: false before you upgrade and create the associations in each account instead.

Identity Center Assignment Failures

The custom resource that creates Identity Center account assignments now reports a failure when a user or group cannot be found in the identity store. Earlier versions reported success to CloudFormation and skipped the assignment, and later deployments did not retry it. A deployment that creates or updates an assignment for a missing user or group now fails with the lookup error. This resolves #1088.

Identity Center in AWS European Sovereign Cloud

In the aws-eusc partition, LZA now enables AWS Organizations trusted access for IAM Identity Center and registers the Identity Center delegated administrator account when identityCenter is configured in iam-config.yaml, as it already did in the aws and aws-us-gov partitions. Earlier versions skipped this step in aws-eusc. This resolves #1160.

Upgrade note: If identityCenter is configured, the first run after the upgrade enables trusted access and registers the delegated administrator account. If a different account is already registered as the Identity Center delegated administrator, LZA deregisters it and registers the configured account, and the deployment fails if Identity Center already has permission sets or assignments that match iam-config.yaml. To keep the current delegated administrator, set identityCenter.delegatedAdminAccount to the name of that account before you upgrade.

SAML Federation in AWS European Sovereign Cloud

In the aws-eusc partition, IAM roles in iam-config.yaml with an assumedBy entry of type provider now have SAML:aud set to https://<home-region>.signin.amazonaws-eusc.eu/saml in their trust policy. Earlier versions rendered an empty SAML:aud value, so AssumeRoleWithSAML could not succeed for these roles. Configure your identity provider with the SAML metadata from the LZA home Region. The first run after the upgrade updates the trust policies in place.

Security Hub Automation Rule Failures

The module that manages AWS Security Hub automation rules now fails the pipeline when the Security Hub API rejects a rule in any Region. Earlier versions logged the error and reported success, so a rule that has been failing without notice now stops the pipeline until you correct it in security-config.yaml.

Quarantine SCP in All Partitions

quarantineNewAccounts now applies in all partitions. Earlier versions applied it only in the commercial aws partition.

SCP Revert on Ignored OUs

When scpRevertChangesConfig is enabled, the SCP revert function no longer reverts SCP attachments or detachments on OUs with ignore: true, including SCPs that LZA manages.

Transit Gateway Attachment Options in Other Partitions

Transit gateway VPC attachment options (applianceModeSupport, dnsSupport, ipv6Support, and securityGroupReferencingSupport) are now applied in partitions other than aws and aws-us-gov. Earlier versions validated these options but did not render them, so attachments used the EC2 defaults, such as ApplianceModeSupport: disable, which breaks multi-AZ Network Firewall inspection VPCs. Only the options set in your configuration are rendered, so deployments that do not set options see no template change.

Configuration Changes That Replace Resources

A new section of the user guide, Configuration Changes That Replace Resources, describes configuration properties that make CloudFormation replace an existing resource the first time you add them, even when the value matches the current behavior. For example, adding multicastSupport with any value, including disable, to a transit gateway that an earlier LZA version created without the property replaces the transit gateway and disrupts all of its attachments. The section also explains how to check for replacements before an upgrade with a CloudFormation change set that you do not execute. This addresses #1096.

Route 53 Resolver Rules at the VPC Level

FORWARD rules defined on outbound endpoints under vpcRoute53Resolver.endpoints[].rules in network-config.yaml are now created, the same way as rules under centralNetworkServices.route53Resolver. Earlier versions accepted these rules in the configuration but did not create them.

Upgrade note: The first run after the upgrade creates the VPC-level rules in your configuration, and shares them when shareTargets is set. Rule names must be unique across central and VPC-level rules.

Wildcard Records for Centralized Interface Endpoints

For VPCs with interfaceEndpoints.central: true, LZA now creates a wildcard record next to the apex record in the private hosted zone of the ecr-fips.dkr and bedrock-agentcore.gateway endpoints. Names that start with an account ID or gateway ID, such as the <account-id>.dkr.ecr-fips.<region>.amazonaws.com names that Docker and OCI clients use, now resolve to the central endpoint. Earlier versions created only the apex record, so these names did not resolve in VPCs that use the central endpoints. The apex record is not changed.

Upgrade note: If you created either wildcard record yourself, delete it before you upgrade, or the NetworkVpcDns stack update fails because the record already exists. Names under the wildcard do not resolve from the time you delete the record until the pipeline creates it, so plan the change for a maintenance window.

Account-Level CloudWatch Logs Subscription Default

When cloudwatchLogs.subscription.type is ACCOUNT and selectionCriteria is omitted, LZA now excludes its own Firehose records-processor log group in the Log Archive account by default, which prevents a log delivery loop. If you provide selectionCriteria, include that exclusion yourself. This resolves #1193.

Metric Filters on the Organization Trail Log Group

Metric filters in security-config.yaml that reference the organization trail's log group (aws-accelerator-cloudtrail-logs by default) are now skipped with a warning when the organization trail is not enabled (logging.cloudtrail.enable and logging.cloudtrail.organizationTrail in global-config.yaml). Earlier versions failed the deployment because the log group does not exist. If you turn off the organization trail later, LZA removes these metric filters. This resolves #327.

Organization Policy Remediation Notifications

SNS notifications from the organization policy remediation function now use the subjects Organization Policy Remediation Failure and Organization Policy Remediation Success instead of Service Control Policy Remediation Failure and Service Control Policy Remediation Success. Update any email rules or automation that match the old subjects.

Control Tower Landing Zone Updates at the Deployed Version

LZA can now update or reset an AWS Control Tower landing zone in place when controlTower.landingZone.version matches the deployed landing zone version (3.1 and later). For in-place operations, LZA reuses the deployed manifest and changes only the fields it manages. The version must still match either the deployed version or the latest available version. Landing zones below version 3.1 must still be set to the latest available version for an update or reset. On version 3.1 and later, a landing zone that has drifted can now be reset at its deployed version, without moving to the latest version.

Control Tower Read-Only Role Access to Encrypted Logs

When LZA manages your AWS Control Tower landing zone (controlTower.landingZone in global-config.yaml), it now gives the aws-controltower-ReadOnlyExecutionRole role in the Log Archive account kms:Decrypt permission on the Control Tower logging KMS key, for requests made through Amazon S3, so that the role can read the encrypted centralized logs. LZA adds the inline policy AWSAcceleratorControlTowerLogDecryptPolicy to the role and the statement AllowControlTowerReadOnlyExecutionRoleToDecryptLogs to the key policy. It reapplies both on every run, so the access is restored after a Control Tower repair recreates the role. If LZA cannot apply them, it logs a warning and the pipeline continues.

New Configuration Checks

New validation checks can stop the pipeline at the Build stage for a configuration that passed validation in v1.16.3. Validation runs before any accelerator stack is deployed, so you can correct the configuration and run the pipeline again. To find these issues before you upgrade, run yarn validate-config <path-to-config> from the source directory of the v1.17.0 code with management account credentials.

A transit gateway or IPAM pool must be shared with every account whose VPC attaches to the transit gateway or allocates from the pool. The check matches OU names exactly, so a share to a parent OU such as Workloads does not cover VPCs in accounts under Workloads/Dev, even though AWS RAM grants those accounts access. List the child OUs or the accounts in shareTargets.
Every account name in organization-config.yaml must be defined in accounts-config.yaml. Earlier versions did not check this file, and they ignored account targets on tag and backup policies. Remove references to accounts that were removed from accounts-config.yaml or moved to an ignored OU.
Route 53 Resolver rule names must be unique across centralNetworkServices.route53Resolver and the VPC-level vpcRoute53Resolver endpoints.
cdkOptions.centralizeBuckets: false is rejected. That setting bootstraps accounts with the default CDK template, so the deployment roles that the Prepare stage assumes are never created. It has been unsupported since v1.14.0.
AWS Config remediation parameter values must fit the AWS Config limits: 256 characters for a String value, and at most 25 values of up to 256 characters each for a StringList value. String values are no longer split at commas, so a long comma-separated String value can now exceed the limit.
Validation also rejects CloudFormation StackSets whose deployment targets resolve to no active accounts, Identity Center assignment principalId values that are not identity store IDs, Application Load Balancer forward listeners without a targetGroup and redirect or fixed-response listeners with one, and AWS Config rule tags with an empty key, a key that starts with aws:, or a key or value over the length limit.

Build Tooling

The solution is now built with Yarn 4 (packageManager: yarn@4.10.3 in source/package.json) instead of Yarn 1 and Lerna. The Yarn binary is included in the source, and script names such as yarn validate-config are unchanged. If you deploy from a modified copy of the source, two installer changes apply. The installer now runs yarn install --immutable, which fails when source/yarn.lock does not match source/package.json. Yarn 4 also does not read source/.yarnrc, so move any registry setting to npmRegistryServer in source/.yarnrc.yml.

Dependency Vulnerability Remediation

Resolved HIGH and CRITICAL severity vulnerabilities in dependencies, including updates to adm-zip, basic-ftp, brace-expansion, fast-uri, handlebars, ip-address, markdown-it, nanoid, postcss, source-map-js, undici, vite, and vitest.

Additional Resources

For full details, please see the CHANGELOG.

awslabs/landing-zone-accelerator-on-aws v1.17.0 on GitHub