Streamlining Cloud Infrastructure Automation with AWS Landing Zone Accelerator (LZA)

In the world of cloud computing, achieving a secure, scalable, and compliant infrastructure is a top priority for organizations of all sizes. However, building this foundational setup—often referred to as a landing zone—can be complex and time-intensive. This is where Landing Zone Accelerators (LZA) step in, offering a streamlined approach to designing and deploying robust cloud environments tailored to meet the unique needs of modern businesses.

In this blog, we’ll dive into the fundamentals of Landing Zone Accelerators, sharing how we’ve simplified multi-account setups, enforced best practices in our own customized way—in addition to AWS-provided standards—and accelerated the journey to operational excellence.

Understanding LZ Vs LZA

Both Landing Zone and Landing Zone Accelerator are two different things.LZ represents a governance concept that works across any cloud, while AWS built LZA as an AWS-native tool.

A landing zone (LZ) is a well-architected, multi-account AWS environment designed to be secure, scalable, and compliant. It serves as a foundational setup for deploying workloads and applications.

The AWS Landing Zone Accelerator (LZA) (an AWS native solution) is a tool that accelerates the deployment of a landing zone. It automates the setup of AWS accounts, organizational units (OUs), and foundational services. It integrates with AWS Control Tower and other AWS services to provide a secure and compliant environment.

Key Features of AWS LZA:

• Multi-Account Structure: It sets up multiple AWS accounts to isolate different environments (e.g., development, testing, production) and workloads.
• Security and Compliance: Implements security controls and compliance policies from the start, ensuring that your AWS environment adheres to best practices.
• Infrastructure Management: As your AWS environment expands, you must ensure that your infrastructure’s security is up to date and that your resources adhere to your governance requirements.
• Security Compliance & Governance: Cloud security is AWS’s highest priority. As organizations embrace the cloud’s scalability and flexibility, AWS is helping them evolve security, identity, and compliance into key business enablers.
• Pre-built framework: AWS Well-Architected comes built in! LZA provides a pre-built, well-architected framework with automation and predefined AWS best practices, which simplifies and accelerates your setup.

• Predefined Industry Architecture with Best Practices:
  • Education
  • Finance/Tax
  • Healthcare
  • State and Local Government IT
  • Aerospace
  • Elections

All the above standardized architectures can be deployed with a few clicks and without much engineering effort. There are two types of deployment: via AWS Organizations and via Control Tower. In this blog, we will cover the Control Tower deployment method. 

Deployment Prerequisites:

Before deploying LZA via AWS control Tower, ensure the following

• Ensure that the Master account has Control Tower enabled.
• Enable the necessary regions.
• Ensure that provisioned accounts are in a successful state if Control Tower is already enabled.
• All accounts should have controltower-execution-role for smooth functioning of LZA.
• Maintain a separate OU for suspending accounts, and move the account you want to suspend into it before suspension. Alternatively, set the root OU as the parent OU for that account and then suspend it.
• Ensure the service quota in CodeBuild [ Concurrently running builds for Linux/Large environment ] is 3 or more.
• Have a Github account and its PAT in Secret Manager with the name accelerator/github-token.
• Email IDs of Management, Log Archive and Audit accounts of your AWS Organizations.

All Set! Deploying the LZA Tool and Diving Deep into Its Components

Note: As part of current best practice, AWS recommends deploying the LZA tool in the Management account that hosts Control Tower.

Deploying LZA via cloudformation stack :

1. Launching the CloudFormation Stack

• Launch the CloudFormation stack using the AWS-provided solution:
  https://docs.aws.amazon.com/solutions/latest/landing-zone-accelerator-on-aws/step-1.-launch-the-stack.html
• Next, review the CloudFormation attributes for deployment.

Provide the stack name as required. AWS recommends using the default name:
AWSAccelerator-InstallerStack, as this tool is currently in the development phase and generally works best with the default values.

2. Github Configuration:

Source – The LZA tool’s code resides in this location. By default, AWS hosts it on GitHub: https://github.com/awslabs/landing-zone-accelerator-on-aws.

This is why a GitHub token is a prerequisite—to fetch the LZA tool’s code into your AWS environment.
Alternatively, you can use CodeCommit as the source by cloning the LZA tool code from GitHub and pushing it to CodeCommit. This process is asynchronous, so you must manually sync any updates to the LZA tool on GitHub.
Also note that AWS plans to deprecate CodeCommit, so use GitHub as the source throughout this blog. When GitHub is the source, updates to the LZA tool automatically reflect because AWS hosts it there.

• Repository Owner – Leave this as awslabs.
• Repository Name – Use the name from the GitHub link (https://github.com/awslabs/landing-zone-accelerator-on-aws) or customize it if you previously chose CodeCommit.
• Branch Name – Refer to the LZA tool GitHub repository and select the latest stable branch.

3. Pipeline Configuration:

After deploying the LZA CloudFormation setup, it creates two pipelines as part of the installation. This blog will discuss them later.

• Enable Approval Stage – Adds a manual approval stage to the LZA pipeline when set to ‘Yes’.
• Manual Approval Stage Notification Email List – Specify the email recipients who receive notifications when approval is required.
• Mandatory Accounts Configuration – As mentioned in the prerequisites, provide the email IDs for the Management, Log Archive, and Audit accounts.

4. Environment Configuration

The LZA tool uses YAML files stored in a repository for configuration. This section specifies the repository that interacts with the LZA tool.

• Set the Control Tower Environment to ‘Yes’.
• Accelerator Resource Name Prefix – Keep the default value: ‘AWSAccelerator’.
• Use Existing Config Repository, Name, and Branch – If you have already configured YAML files for the LZA tool, provide the required details; otherwise, leave the default settings.
• Enable Diagnostics Pack – This option helps debug any issues that arise with the LZA tool. Set it to ‘Yes’.

Once all the above configurations are complete, deploy the CloudFormation stack. After the deployment finishes, you should see one or two CodeCommit repositories and two CodePipeline pipelines.

CodePipeline:

 

AWS-Accelerator-Installer — The LZA tool uses this pipeline internally to upgrade its version.

AWS-Accelerator-Pipeline—This is the primary LZA pipeline, which we will use to implement our architecture.

AWS-Accelerator-Pipeline Stages Overview:

• SOURCE STAGE—Will have two sources of repositories to trigger.
  • Landing Zone Accelerator tool hosted on AWS Github
  • Config files repo [default name – aws-accelerator-config]

• BUILD STAGE — Validate configuration file inputs and syntaxes.
• PREPARE STAGE — Create new AWS accounts or validate existing accounts for updated configurations.
• ACCOUNTS STAGE — Validate accounts against the infrastructure, including OU structure and SCPs.

• BOOTSTRAP STAGE—Internally, LZA uses CDK bootstrap for the deployments.  Please refer to the document provided at https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html

• REVIEW STAGE — Enable this optional stage when configuring the initial CloudFormation deployment.
  • DIFF — Generate bit-encrypted logs that show differences between the existing environment and the environment to be deployed.
  • APPROVE — Manually approve changes to deploy them.
• LOGGING STAGE—Packed with two stages, KEY and LOGGING.  At the backend, LZA will create resources on its own to run itself.  LZA will use KMS encryption at rest for applicable resources. Designate centralized logging in the logging account using Amazon Kinesis Data Streams and Amazon Kinesis Data Firehose.
• ORGANIZATION STAGE—Will deploy some organization-wide trusted services, backup, and tagging policies
• SECURITY_AUDIT STAGE—Organization-wide centralized security services like Macie, Guard Duty, and Security Hub.
• DEPLOY STAGE—Several deployments will happen here.
  • Network_Prepare—preparing references for network resources such as subnets and transit gateways. These resources are not deployed at this point; only their references are created.
  • SecurityMember account security services are configured
  • OperationsIAM users, groups, and roles are deployed
  • Network_VPCs—Three stacks are deployed during this stage, each related to VPC networking:
  • NetworkVpcStack—VPCs, subnets, route tables, security groups, and other associated resources are deployed. AWS Transit Gateway attachments are created, if configured.
  • NetworkVpcEndpointsStack—VPC endpoints, including Route 53 resolver endpoints and AWS Network Firewall endpoints, are deployed.
  • NetworkVpcDnsStack—Route 53 private hosted zones and resolver rules are deployed.
  • IdentityCenterAWS IAM Identity Center account assignments and permission sets are deployed in the organization.
  • Security_Resources—Security services for member accounts such as AWS Config, CloudWatch metrics, and alarms are deployed.
  • Network_Associations—The solution deploys two stacks during this stage, each related to network associations that depend on resources created in the Network_VPCs stage:
    • NetworkAssociationsStack—Network associations that depend on Amazon VPC resources to be created, such as AWS Transit Gateway VPC associations, are deployed.
    • NetworkAssociationsGwlbStack—Network associations that depend on Gateway Load Balancers to be created, such as Gateway Load Balancers and VPC endpoints, are deployed.
  • Finalize — Remove the quarantine SCP during this action if you use the account quarantine feature for new account creation.

Code Repository

AWS-ACCELERATOR-CONFIG will serve as the repository for configuration files, and the system creates it in the CodeCommit repository of your management account.

• yaml—used to manage global properties like setting home_region and enabled regions, enabling logs and cloudtrails, configuring budgets, etc.
• Network-config.yaml—Used to deploy networking resources and create WLAN/Transit Gateway setup.
• accounts-config.yaml—Will be used to configure AWS accounts and associate them with their corresponding OU. Nested OUs can be implemented via the “/” character—ou/nested_ou/account. Furthermore, it will have 3 mandatory accounts—the Management account (MPA), LogArchive, and Audit accounts. Additionally, each of these accounts will include workload accounts.
• iam-config.yaml—Used to deploy IAM roles, permission sets, and user groups.
• organization-config.yaml—Used to deploy organizational units, service control policies, tagging policies, and backup policies.
• security-config.yaml—Implementing centralized security services like Macie, GuardDuty, Security Hub, Config, CloudWatch, etc.
• customizations-config.yaml—Implementing customized CloudFormation stack sets and stacks.

KEY RESOURCES DEPLOYED WITH THE SOLUTION AND THEIR ROLE

All set! Let’s explore real-time use cases:

Prerequisite for deployments: accounts-config.yaml with the mandatory account management, log archive, and audit accounts, and create workload accounts if necessary.

Ensure the AWS-ACCELERATOR-CONFIG repository is available locally for editing, and push it back after completing the snippets. The LZA pipeline automatically triggers and waits at the approval stage as configured.

Account/OU Onboarding:

Organization Unit: Use the organization-config.yaml file to update the necessary OU as follows.

If the new workload will be in the new OU, which is not present in the organization-config.yaml file, add the OU in the organizationalUnits header.

File: organization-config.yaml

organizationalUnits:
  - name: 
    ignore: <true/false>
  - name: 
    ignore: <true/false> 

If it is a nested OU, add the parent OU first • Then add the child OU with the “/” character—{parent}/{child}.

File: organization-config.yaml

OrganizationalUnits
  - name: Compliance
  - name: Compliance/HIPAA

• Account Onboarding—In the accounts-config.yaml file for the relevant AWS account. Populate the mandatory accounts block if it isn’t already populated. Please locate the workloadAccounts section and add the target AWS account.
  • Provide the necessary inputs, such as name, description, email, and organizational unit (OU), for the new AWS account in the standard format.

File: accounts-config.yaml

workloadAccounts:
  - name: 
    description: 
    email: 
    organizationalUnit: 

Achieving HIPAA Compliance for Your Organization: Best Practices and Strategies

Achieving HIPAA Compliance via LZA is quite trickier. Here, we will combine the concepts of conformance pack (AWS Service) and customizations (LZA).

HIPAA Conformance Pack:

AWS provides a ready-made conformance pack designed to help organizations meet compliance standards, including HIPAA. Download the recommended AWS conformance pack YAML file from the AWS Documentation and customize it as needed to align with your organization’s compliance requirements. Additionally, maintain a separate folder for Conformance templates to manage the deployment of the conformance pack efficiently. Ensure proper structuring of these files within the project directory to maintain clarity and ease of access.

• Customize the HIPAA conformance YAML and upload it to the S3 bucket in the AWS account where you deployed LZA.
• Create the cloudformation template for deploying this conformance pack as follows and have the S3 details filled.

File: Conformance/HIPAA/hipaa-conformance.yaml

AWSTemplateFormatVersion: '2010-09-09'
Description: AWS Config Conformance Pack Template

Resources:
  ComplianceConformancePack:
    Type: "AWS::Config::ConformancePack"
    Properties:
      ConformancePackName: ""
      TemplateS3Uri: "s3:///.yaml"
      DeliveryS3Bucket: ""
      DeliveryS3KeyPrefix: "/"

Customizations:

Use customizations-config.yaml to deploy stacks or stack sets across multiple regions.  Fill the template as follows:

File: customizations-config.yaml

customizations:
  cloudFormationStackSets: []
  cloudFormationStacks:
    - name: 
      description: 
      regions:
        - 
        - 
      deploymentTargets:
        organizationalUnits:
          - 
      runOrder: 
      template: 
      terminationProtection: <true/false>

You can deploy it in multiple regions as needed by using region attributes.

After you make and commit the above configurations, the LZA Pipeline (AWSAccelerator-Pipeline) automatically triggers and deploys the resources once the pipeline stages pass successfully.

LZA Validator

The LZA Validator validates your LZA configurations on the AWS Landing Zone Accelerator (LZA). It helps you ensure that your Landing Zone setup is compliant with the expected standards and correctly configured for deployment. The system packages it as a lightweight Docker container, which makes it easy to run without installing additional dependencies.

Setting Up the LZA Validator

Before you can use the LZA Validator, you need to build the Docker image. Here’s how:

Step 1: Clone the Repository

Start by cloning the LZA Validator GitHub repository to your local system:

git clone <https://github.com/aws-samples/lza-validator.git> cd lza-validator

Step 2: Build the Docker Image

Once you’re in the project directory, run the following script to build the Docker image:

./build.sh

This script will:

• Build the Docker image locally using the Dockerfile provided in the repository.
• Tag the image for use in running validation commands.

Running the LZA Validator

After building the Docker image, you’re ready to validate your Landing Zone configurations. Use the following command to run the LZA Validator:

docker run --rm -v $(pwd):/app/input -w /app/input lza-validator:latest validate

Cost Considerations

The monthly cost of running the Landing Zone Accelerator on AWS in the US East (N. Virginia) Region with no activity or workloads is approximately $430.22 USD, with several key cost drivers contributing to this total. AWS CloudTrail accounts for $99.00, primarily due to 4 million read/write management events and 4.7 million paid events. The Config adds $23.00 for tracking 2,000 configuration items and performing 17,000 rule evaluations. AWS Key Management Service (KMS) incurs a cost of $44.56, driven by 43 customer-managed keys and over 521,000 symmetric requests. Networking costs, totaling $175.35, are significant, resulting from two Transit Gateway attachments and 14 VPC endpoints with a combined 6 GB of data usage.

Monitoring and logging costs include $15.71 for Amazon CloudWatch, which manages 12 metrics and 12 GB of logs, and $11.52 for Amazon GuardDuty, which analyzes management and Amazon S3 data events. Storage on Amazon S3 costs $2.79 for 7 GB of standard storage and approximately 770,000 combined PUT and GET requests. Security and compliance services add $30.00 for AWS Security Hub, $1.60 for Amazon Macie to monitor 16 S3 buckets, and $0.81 for AWS Secrets Manager managing two secrets. Lastly, pipeline and build services include $1.00 for AWS CodePipeline (two pipelines) and $6.00 for AWS CodeBuild, which supports 60 builds of 5 minutes each.

This estimate provides an overview of costs in a sandbox environment, and AWS recommends creating budgets using AWS Cost Explorer to manage and optimize expenses effectively.

Conclusion

With the LZA tool successfully deployed and its components analyzed, we now have a strong foundation to enhance security, compliance, and scalability. By reviewing AWS Organizations, Config Conformance Packs, Networking, and Security, we’ve ensured a well-structured and optimized cloud environment. With predefined industry architectures, automated pipelines, and integrated best practices, LZA becomes a powerful solution for organizations aiming for operational excellence in the cloud.