Skip to content

v1.16.0

Latest
Latest

Choose a tag to compare

View all tags
@rycerrat rycerrat released this 29 Jul 20:23
v1.16.0
6b9b255

Release Notes v1.16.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.

Update your Service Control Policies after upgrading. v1.16.0 introduces the module orchestration framework, which adds new module-infrastructure resources to the installer stack: two DynamoDB tables (<acceleratorPrefix>-Module-State-* and <acceleratorPrefix>-Resource-Retention-*) and a CloudWatch log group. It also migrates Amazon Macie and Transit Gateway associations and propagations to the module pattern.

For external-pipeline and container deployments, LZA names these resources with a custom qualifier (for example, lza1-) instead of the AWSAccelerator prefix. Existing SCP resource patterns match AWSAccelerator*, so they may not cover the qualifier-named resources. If you run an external-pipeline or container deployment, update your SCPs after upgrading to include the qualifier-prefixed resource names, so the new resource types fall under guardrail coverage. Standard (internal) deployments use the AWSAccelerator prefix and require no SCP change.

New Features

Module orchestration

LZA v1.16.0 introduces a module orchestration framework that moves selected resources from CloudFormation-managed to module-managed (direct API) ownership. A shared engine (runner.ts and module-orchestration.ts) executes service modules with DynamoDB-backed state management, credential caching, and structured logging, and a cfn-retention subsystem safely transitions existing CFN-managed resources by applying DeletionPolicy: Retain before the module takes ownership. Amazon Macie and Transit Gateway associations/propagations are the first two migrations built on this framework. The framework also skips a module when its configuration has not changed since the last successful run (logging Skipping module <name> as configuration has not changed since last execution), which reduces pipeline time when only some modules have configuration changes. This is automatic and requires no configuration. Because the migration adopts existing resources in place rather than recreating them, migrated resources continue to function as before with no expected downtime.

Transit Gateway associations and propagations module

LZA now manages Transit Gateway route table associations, propagations, and Direct Connect gateway associations through a dedicated module instead of individual CloudFormation resources. This resolves the CloudFormation 500-resource stack limit that caused deployment failures in large environments with many VPC attachments.

Key improvements:

  • Stack resource reduction: TGW associations and propagations are no longer individual AWS::EC2::TransitGatewayRouteTableAssociation/Propagation CFN resources. The module manages them through direct API calls, which removes the resource count ceiling.
  • Resource retention safety: a retention registry preserves existing CFN-managed TGW resources with DeletionPolicy: Retain before the module takes ownership, which prevents accidental deletion during migration.
  • Direct Connect gateway associations: same-account DX gateway associations are created directly. Cross-account associations are submitted as proposals that the DX gateway owner must accept out-of-band, and they remain in requested state until accepted. Route table associations and propagations cannot be defined on a cross-account proposal.

Upgrade note: For environments that set stackPolicy.enable: true in global-config.yaml, migrating TGW route table associations and propagations to the module requires removing AWS::EC2::TransitGatewayRouteTableAssociation and AWS::EC2::TransitGatewayRouteTablePropagation from protectedTypes. Do this either by editing protectedTypes in global-config.yaml or by updating the stack policy manually on the existing Network-account stacks. If neither is done and the stack policy still protects these types when the migration runs, CloudFormation blocks the update and it fails with UPDATE_ROLLBACK_COMPLETE. This removal is permanent. Once migrated, these resources are managed by the module rather than as CloudFormation-native objects, so re-adding them to protectedTypes has no effect and is not needed. The migrated resources are retained (DELETE_SKIPPED, not destroyed) and the module takes ownership. TGW static routes (AWS::EC2::TransitGatewayRoute) are not part of this migration. They remain CloudFormation-managed and should stay in protectedTypes.

Macie module

Migrated Amazon Macie from CloudFormation custom resources to the module pattern. This migration:

  • Adds CloudFormation resource retention: a cfn-retention subsystem transitions Macie resources from CFN-managed custom resources to module-managed API calls by applying DeletionPolicy: Retain before stack updates.
  • Includes a full integration test framework: new test infrastructure (framework/) with account resolution, manifest loading, state table assertions, and prerequisite shell scripts enables end-to-end testing of module deployments.
  • Provides architecture documentation: a new security-service-orchestration.md documents the module pattern for future security service migrations (GuardDuty, SecurityHub, Detective).

Note: This migration is transparent to customers. Existing Macie configurations in security-config.yaml continue to work without changes. The module handles enable/disable, member management, classification export configuration, and delegated admin setup through direct API calls instead of CloudFormation custom resources.

Static HTML configuration diff viewer

LZA now generates a self-contained static HTML diff report during pipeline execution, providing a visual side-by-side comparison of CloudFormation template changes before deployment. During the pipeline run, the diff report is written to the accelerator pipeline S3 bucket under Diffs/<pipelineExecutionId>/diff-viewer.html. The pipeline's Review stage pauses for manual approval, and the approval message points to that S3 location so approvers can review the CloudFormation changes before approving the deployment.

IAM role trust policy conditions

LZA now supports per-principal trust policy conditions on IAM roles defined in iam-config.yaml. Each assumedBy entry can include a conditions array specifying IAM condition operators (StringEquals, ArnLike, StringLike, etc.), condition keys, and values. Conditions are merged with any existing role-level externalIds, enabling fine-grained control such as restricting assume-role to specific aws:PrincipalOrgID values or source VPCs.

The implementation refactors the principal generation from a batch approach to per-principal statement emission, with each principal getting its own trust policy statement and merged conditions. Validation ensures condition operators and keys are valid before synthesis.

# Example iam-config.yaml
roleSets:
  - deploymentTargets:
      accounts: [Management]
    roles:
      - name: CrossAccountRole
        assumedBy:
          - type: account
            principal: "123456789012"
        conditions:
          - type: StringEquals
            key: "aws:PrincipalOrgID"
            values:
              - "o-abc123def4"

VPN route propagation on route tables

Added a new enableRoutePropagation boolean property on route tables in network-config.yaml. When set to true and a Virtual Private Gateway is defined for the VPC, LZA creates a CfnVPNGatewayRoutePropagation resource that automatically propagates BGP-learned routes from the VPN gateway into the specified route tables. This eliminates the need for manual static route management for Site-to-Site VPN connections.

Session policy framework for module least-privilege enforcement

LZA now applies scoped session policies to every module execution, constraining each module's cross-account credentials to the minimum set of actions it requires instead of relying on broad administrative access. This hardens the module orchestration framework introduced in this release.

Control Tower control parameters

Control Tower controls defined under controlTower.controls[] in global-config.yaml now support a parameters property, allowing customers to pass parameter values to parameterized enabled controls (for example, controls that accept a region list or other configuration input).

Custom Route 53 hosted zone name

Added an optional hostedZoneName property in network-config.yaml, letting customers override the default hosted zone name used for VPC interface endpoints. The value is capped at 1024 characters to match the Route 53 CreateHostedZone limit.

Transit Gateway Connect route table associations and propagations

Transit Gateway Connect attachments (TransitGatewayConnectConfig) now support routeTableAssociations and routeTablePropagations properties, referencing TGW route tables by their logical name in network-config.yaml. This brings Connect attachments to parity with VPC and Direct Connect attachments for route table wiring.

Gateway Load Balancer listener TCP idle timeout

Added an optional tcpIdleTimeout property on Gateway Load Balancer listeners in network-config.yaml, allowing customers to tune the TCP idle timeout for GWLB flows.

Changes

Identity Center Delegated Admin

Previously, LZA registered an Identity Center delegated administrator even when the identityCenter property was not defined in the IAM configuration. This has been corrected, so delegated admin registration now only occurs when identityCenter is explicitly configured. Customers who did not define identityCenter in their config but rely on the delegated admin account for managing Identity Center resources should either add the identityCenter configuration block or re-register the delegated admin manually before upgrading, because the delegated admin will be deregistered during the upgrade. Existing permission sets and user access are not affected.

IP-type Target Group Registration

Previously, IP-type target groups did not set AvailabilityZone for static IP targets, preventing cross-VPC target registration. NLB and ALB target groups with IP targets now correctly set AvailabilityZone: "all", enabling targets outside the VPC CIDR range to receive traffic.

Upgrade note: Existing deployments with IP-type target groups using static IP targets will see a CloudFormation diff on the next pipeline run. This triggers a target deregistration/re-registration cycle that may briefly reduce capacity while health checks converge (~2.5 minutes per target). For in-VPC targets, the behavior is functionally unchanged. We recommend scheduling the first pipeline run after this upgrade during a maintenance window if your IP target groups serve production traffic.

S3-only VPC flow logs (v2 network stack)

Previously, when a VPC's vpcFlowLogs was configured with destinations: [s3] (or any list excluding cloud-watch-logs) on the v2 network stack, LZA incorrectly synthesized a CloudWatch flow log alongside the S3 flow log. With this fix, only the destinations explicitly listed are created. v1 network stacks were not affected.

Upgrade note: If you used a destinations list that excluded cloud-watch-logs on the v2 network stack and saw an unwanted CloudWatch flow log created, the next pipeline run will automatically remove the AWS::EC2::FlowLog resource and its IAM role from your stack. The underlying CloudWatch log group is retained (it uses RETAIN_ON_UPDATE_OR_DELETE to protect against accidental log deletion) and must be deleted manually in each affected account/region if it is not desired. Only customers running v2 network stacks (useV2Stacks: true) who explicitly opted out of cloud-watch-logs are impacted.

Additional Resources

For full details, please see the CHANGELOG.

Assets 2
Loading