Landing Zone Accelerator on AWS (LZA)

The GovCloud (US) configuration is a specialized deployment of the Landing Zone Accelerator (LZA) on AWS designed to automate the setup of cloud environments in AWS GovCloud (US). It establishes platform readiness by implementing security, compliance, and operational capabilities.

Compliance Frameworks

The solution is architected to align with the following control requirements:

• FedRAMP (Federal Risk and Authorization Management Program)
• NIST 800-53(5)
• NIST 800-171 Rev.2
• CMMC (Cybersecurity Maturity Model Certification) Level 2

Key Characteristics

• Guardrails: Applies preventative and detective guardrails to vended accounts to help align workloads with compliance requirements.
• Acceleration, not full compliance: The LZA is intended to accelerate deployments, migrations, and refactoring by reducing manual infrastructure effort. It provides foundational infrastructure but is not a complete compliance solution; users must tailor the environment to their specific business needs.
• AWS Control Tower Integration: New deployments automatically leverage AWS Control Tower to streamline the multi-account environment. Existing customers using AWS Organizations can continue with their current configuration.

The Landing Zone Accelerator on AWS (LZA) uses YAML configuration files to manage the lifecycle of a multi-account environment. These files define AWS account settings and service configurations to meet specific compliance objectives and automate administrative tasks.

Key capabilities enabled via configuration files include:

• Security & Guardrails: Configuring AWS Config Managed Rules and AWS Security Hub.
• Networking: Managing foundational topology including Amazon VPC, AWS Transit Gateway, and AWS Network Firewall.
• Account Management: Integrating with AWS Control Tower Account Factory or AWS Organizations to generate workload accounts.

Note: This specific documentation focuses on the general sample configuration. For industry-specific configurations, refer to the LZA reference repository. It is highly recommended to follow the best practices for managing configuration files before applying changes.

Landing Zone Accelerator on AWS (LZA) is an open-source Infrastructure as Code (IaC) solution built using the AWS Cloud Development Kit (CDK). It is designed to complement AWS Control Tower by providing a low-code way to manage and govern multi-account environments across 35+ AWS services.

Key Capabilities:

• Configuration: Use simplified configuration files to enable security services (e.g., AWS Managed Config Rules, AWS Security Hub).
• Networking: Manage foundational networking topology including VPCs, Transit Gateways, and Network Firewall.
• Account Management: Generate additional workload accounts using the AWS Control Tower Account Factory.
• Compliance: Aligns with AWS best practices and global compliance frameworks.
• Partitions: Supports standard AWS partitions as well as AWS GovCloud (US) and US Secret/Top Secret regions.

Cost Model: There are no additional charges for the LZA software itself. You only pay for the AWS services consumed by the deployed infrastructure and controls.

The Security stack is deployed to all accounts in all enabled regions during the security stage. It deploys the following resources:

• Amazon Macie: Enables Macie sessions and configures export of classification results to the central logs bucket. It respects the excludeRegions configuration.
• Amazon GuardDuty: Enables GuardDuty detectors and configures feature flags like S3 and EKS protection. It respects the excludeRegions configuration.
• AWS Security Hub: Enables Security Hub and specified security standards (CIS, AWS Foundational, PCI DSS). It respects the excludeRegions configuration.
• EBS Default Volume Encryption: Enables default EBS encryption with a dedicated CMK per account/region. The key alias follows the pattern: alias/<prefix>/ebs/default-encryption/key.
• IAM Password Policy: Updates the account-level IAM password policy.
• Accelerator Metadata Rule: An AWS Config custom rule that tracks accelerator metadata such as bucket names and key ARNs.
• Config Aggregation: In the aggregation account, creates a Config aggregator that spans all accounts.

When using !include within an array, the structure of your included file must match how you include it to avoid nested arrays or schema errors.

Option 1: Including a file that contains an entire array

If the included file starts with array markers (-), use it as a mapping value (no dash before the directive).

Main file:

workloadAccounts: !include include/all-workload-accounts.yaml

Included file (include/all-workload-accounts.yaml):

- name: SharedServices
  description: ...
- name: Network
  description: ...

Option 2: Including multiple files that each contain a single object

If each included file contains only one object (no - markers), include them as individual list items.

Main file:

workloadAccounts:
  - !include include/shared-services-account.yaml
  - !include include/network-account.yaml

Included file (include/shared-services-account.yaml):

name: SharedServices
description: The SharedServices account

⚠️ Common Mistake: Creating Nested Arrays

Do not use a list marker (-) if the included file already contains an array. This results in a nested array structure that will cause schema validation errors.

Incorrect:

workloadAccounts:
  - !include include/dev-accounts.yaml    # File contains an array
  - !include include/prod-accounts.yaml   # File contains an array
# Result: workloadAccounts[0] is an array, not an object

# Option 1: Mapping value for an entire array
workloadAccounts: !include include/all-workload-accounts.yaml

# Option 2: List items for individual objects
workloadAccounts:
  - !include include/shared-services-account.yaml
  - !include include/network-account.yaml

LZA uses a multi-step workflow to centralize CloudWatch Logs into the aws-accelerator-central-logs S3 bucket in the Log Archive account:

1. Log Group Update: During the Logging stage, a Lambda function (invoked by a CloudFormation custom resource) updates log groups to enable encryption with the account-level CloudWatch AWS KMS key, apply a subscription filter, and ensure the retention period meets the solution's requirements.
2. Subscription Destination: The subscription filter points to an Amazon Kinesis Data Stream in the Log Archive account.
3. Automation: An EventBridge rule monitors for new log groups in core and workload accounts and triggers a Lambda to apply the same encryption, subscription filter, and retention settings.
4. Streaming & Transformation: Logs stream to the Kinesis Data Stream (encrypted with the replication AWS KMS key), which feeds into a Kinesis Data Firehose delivery stream.
5. Centralized Storage: Firehose delivers the transformed logs to the aws-accelerator-central-logs S3 bucket (encrypted with the central logging AWS KMS key).