View a markdown version of this page

Build landing zone - AWS Transform
Connector setupFoundation setupWorkload account designIaC formatsDeployment approvals processTag landing zone resourcesReversing changesRelated resources

Build landing zone

AWS Transform guides you through designing and deploying an AWS landing zone as part of your migration project. A landing zone is a multi-account AWS environment that serves as the foundation for your workloads with organizational boundaries, governance controls, and account structure in place before any workloads arrive. AWS Transform analyzes your migration inventory and business requirements to recommend an Organizational Unit (OU) and account structure, apply recommended Service Control Policies (SCPs), and generate and/or deploy the infrastructure as code (IaC).

The landing zone agent walks you through two phases:

  • Foundation setup – Establish the core landing zone structure: AWS Control Tower, foundational OUs, and core accounts.

  • Workload account design – Design and create workload OUs and accounts based on your migration waves, business units, and environment separation requirements.

AWS Transform supports both greenfield environments (no existing landing zone) and brownfield environments (existing OUs and accounts already deployed). In brownfield scenarios, AWS Transform detects your existing organization structure and recommends only the changes needed to fill gaps against AWS best practices.

Connector setup

The landing zone agent requires a target AWS account connector to provision resources in your organization management account. The connector has permissions to:

When you approve the connector request, you grant AWS Transform permissions to:

  • Provision and manage landing zone infrastructure in the target AWS account and Region. This includes permissions for the following items, restricted to resources tagged with CreatedBy:AWSTransform and by ATWorkspace:{workspace-id} where applicable:

    • S3 bucket operations (create, read, write, delete) for buckets starting with transform-vmware-landing-zone-

    • CloudFormation stack deployments and change set management for landing zone stacks

    • AWS Control Tower operations (managing landing zones, enabling baselines and controls)

    • AWS Organizations management (creating and managing organizational units, creating accounts, and moving accounts)

    • Service control policy (SCP) management via AWS Control Tower

    • AWS Service Catalog provisioning artifact management

When you create the connector, you specify a target AWS Region. This Region should be the same as your home Control Tower Region. For more information about Control Tower Regions, see How AWS Regions work with AWS Control Tower.

At the start of the landing zone setup, AWS Transform retrieves your connector configuration and presents the AWS Organization management account ID and target Region for confirmation. For more information, see AWS Transform Connectors.

Important

IAM Identity Center Region dependency – AWS Transform requires AWS IAM Identity Center (IAM Identity Center), which means your connector Region must match both your AWS Control Tower home Region and your IAM Identity Center Region. If IAM Identity Center is already configured in your organization, AWS Control Tower initialization will fail if the connector targets a different Region. For more information, see Considerations for IAM Identity Center customers in the AWS Control Tower User Guide.

Foundation setup

The foundation setup phase establishes the core landing zone infrastructure using AWS Control Tower. When AWS Control Tower sets up a landing zone, it automatically provisions a set of managed resources in your management account that form the governance foundation for your entire AWS Organization:

  • Root – The top-level parent that contains all OUs in your landing zone.

  • Security OU – Created automatically by Control Tower. Contains two shared accounts: the Log Archive account (centralized, immutable logging for all AWS API activity and resource changes across your organization) and the Audit account (read-only access to all accounts for security and compliance review). These accounts cannot be renamed or replaced after initial setup.

  • Mandatory controls (guardrails) – Control Tower automatically applies preventive and detective controls across your organization to enforce baseline governance policies. These cannot be disabled.

  • IAM Identity Center directory – Control Tower creates a cloud-native directory with preconfigured groups and single sign-on access for your landing zone users. For more information, see AWS IAM Identity Center.

Control Tower uses CloudFormation StackSets to deploy and manage these resources consistently across all accounts and Regions in your organization. You must not modify or delete Control Tower managed resources outside of supported methods, as doing so can cause your landing zone to enter an unknown state.

Account email convention

AWS requires a unique email address for each account. These emails receive important notifications for the account. AWS Transform uses plus addressing to generate unique account emails from a single mailbox.

Format: prefix+account-name@domain

You provide a prefix (for example, aws-admin) and a domain (for example, acme.com), and AWS Transform derives all account emails automatically. For example:

  • Audit account: aws-admin+audit@acme.com

  • Log Archive account: aws-admin+log-archive@acme.com

  • Sandbox account: aws-admin+sandbox@acme.com

In brownfield scenarios, AWS Transform inspects existing account emails to infer the plus-addressing convention already in use and offers to continue with the same pattern.

Recommended foundation structure

Based on AWS best practices, AWS Transform recommends the following foundation OU structure. You can customize it before creation.

OU Purpose Accounts
Security Centralized audit logging and monitoring. Isolating these services in dedicated accounts is designed to help keep your audit trail separate from workload teams. Audit, Log Archive
Infrastructure Shared networking (Transit Gateway, VPN), DNS, and common services. Centralizing these is recommended to help reduce duplication and give your network team a single place to manage connectivity. None (created empty)
Sandbox Developer experimentation with spending limits and restricted access. Recommended to give developers a space to experiment without risking production resources. Sandbox
Workloads Contains Production, Non-Production, and optionally Regulated sub-OUs. Workload accounts are designed in the next phase based on your migration requirements. None (created empty)
Note

The Security OU with Audit and Log Archive accounts is created as part of the Control Tower foundation setup. The Infrastructure, Sandbox, and Workloads OUs are created separately after you confirm the structure.

In brownfield scenarios, AWS Transform compares your existing foundation against this recommended structure and reports only the gaps. For example: "Your foundation has Security and Infrastructure OUs but no Sandbox OU."

Service Control Policies (SCPs)

SCPs are organization-level permission guardrails that set the maximum permissions for all accounts in your AWS Organization. They don't grant access — instead, they define boundaries that no one in the account can exceed, even account administrators.

As part of the Control Tower deployment, baseline guardrails are applied automatically. AWS Transform also recommends additional SCPs designed to help strengthen your organization's posture. These are based on AWS best practices for a minimum viable landing zone.

SCPs can be applied to the Infrastructure, Sandbox, and Workloads OUs. The Security OU is managed by Control Tower and cannot be targeted by SCPs through this tool.

Important

The Security OU is a foundation OU managed by Control Tower. You cannot add accounts, SCPs, or any resources to it through the landing zone agent.

In brownfield scenarios, AWS Transform checks which SCPs are already applied and only recommends ones that would fill gaps.

Foundation deployment

After the foundation design is complete, you choose how to deploy:

  • Deploy for me – AWS Transform deploys the foundation OUs, accounts, and SCPs to your AWS Organization.

  • I'll deploy on my own – AWS Transform generates Infrastructure as Code (IaC) artifacts for download in your preferred format (see IaC formats).

  • Design workload accounts first – Skip deployment and continue to the workload account design phase. You can deploy everything together later.

Control Tower initialization

If AWS Transform detects that AWS Control Tower is not yet initialized in your organization, it provides the user with a link to the AWS Transform console page. Generating the operation in the link will create a CloudFormation stack to bootstrap Control Tower. The process will create this stack in the CloudFormation console for your target Region. After the stack creation is complete, AWS Transform continues with the deployment.

Workload account design

In the workload account design phase, AWS Transform designs the OU and account structure for your application workloads based on your migration inventory, business requirements, and environment separation preferences.

Migration planning context

AWS Transform retrieves data from your migration planning phase, including wave plans, server-to-application mappings, and shared context. If migration planning data is available, AWS Transform displays a summary and asks you to confirm or adjust it. If no migration planning data is available, AWS Transform asks discovery questions directly.

Discovery

AWS Transform asks questions to understand your workload requirements. You can skip any question. Topics include:

  • Number of business units or teams using AWS

  • Industry and any applicable frameworks (HIPAA, PCI-DSS, SOC2, FedRAMP)

  • Whether workloads handle sensitive data (PII, PHI, financial)

  • Environment separation preferences (dev/test/staging/prod as separate accounts or shared)

  • Workload isolation requirements

  • Business applications and their purposes

  • Server grouping into applications

  • Cost tracking and allocation needs (by business unit, project, environment)

  • Expected growth in the next 12–24 months

  • Account strategy preference (single app per account, grouped, or environment-based)

Proposed workload structure

Based on your answers and migration planning data, AWS Transform proposes an OU and account structure under the Workloads OU. The proposal includes the reasoning behind each design decision.

AWS Transform follows these design principles:

  • All servers in a migration wave go to the same account — waves cannot be split across accounts. This is a rehost limitation during wave execution.

  • If you request isolated environments, AWS Transform creates Workloads/Production and Workloads/Non-Production sub-OUs.

  • If applicable frameworks are identified, AWS Transform creates Workloads/Regulated and Workloads/Standard sub-OUs.

  • If multiple business units require different governance, AWS Transform creates business-unit-specific OUs under Workloads.

  • Critical or sensitive-data applications get a single app per account. In this case, you might be asked to iterate on your wave plan.

  • Tightly coupled applications with shared dependencies are grouped in one account.

Each proposed account includes: name, purpose, target OU, and business unit. AWS Transform shows the naming convention being used (for example, <business-unit>-<environment>-<workload>).

You can review and modify the proposed structure before AWS Transform applies the changes. After applying, you can iterate — making additional changes until you are satisfied.

Workload SCP configuration

After the workload structure is created, AWS Transform presents available SCPs and asks if you want to apply any to your workload OUs. You select which SCPs to apply and to which OUs. AWS Transform applies the SCPs and shows the updated organization tree with an SCP summary table.

Workload deployment

After the workload design is complete, you choose how to deploy:

  • Deploy for me – AWS Transform deploys the workload OUs, accounts, and SCPs to your AWS Organization.

  • I'll deploy on my own – AWS Transform generates IaC artifacts for download in your preferred format (see IaC formats).

IaC formats

When you choose self-deployment, AWS Transform generates Infrastructure as Code artifacts in the following formats:

  • AWS Cloud Development Kit (AWS CDK) – TypeScript project for programmatic infrastructure deployment.

  • Landing Zone Accelerator (LZA) – Configuration YAML files based on LZA Universal Configuration version 1.1.0. These enterprise-ready templates work with the Landing Zone Accelerator on AWS to establish multi-account AWS environments. The generated files include pre-configured settings for governance, organization structure, and networking that align with AWS best practices. To learn more, see LZA Universal Configuration.

Note

When deploying via the Landing Zone Accelerator (LZA) pipeline, your AWS Transform account and LZA installation must be in the same AWS Organization. Deployment will fail if there is a mismatch between the Organizations IDs used in AWS Transform and LZA. To learn how to set up your LZA installation using Organizations, see AWS Organizations based installation.

After you select a format, AWS Transform generates the artifacts and makes them available for download.

To verify the downloaded file hasn't been corrupted or tampered with, generate and download a checksum, then compare it to a locally generated hash using:

openssl dgst -sha256 -binary <file.zip> | base64

Deployment approvals process

Landing zone deployment requests require explicit approval before execution. When you submit a deployment request, it automatically routes to authorized approvers through the AWS Transform Approvals tab.

Approvers review CloudFormation templates and landing zone configurations. Only users with the Admin role in AWS Transform can approve deployment requests. Each submission triggers a new review cycle, and deployments proceed only after receiving confirmation.

If an approver denies your request, contact them directly to discuss necessary modifications. The system tracks all approval decisions for audit purposes and maintains deployment history.

Tag landing zone resources

AWS Transform automatically tags all generated resources with "CreatedBy": "AWSTransform" along with definition and execution IDs for tracking purposes.

Automatic tags

All landing zone resources receive the following tags:

  • CreatedBy – AWSTransform

  • ATWorkspace – Workspace identifier

Note

If your migration is part of the AWS Migration Acceleration Program (MAP 2.0), you can include the required MAP tag: Key: map-migrated Value: migMPE_ID (where MPE_ID is your Migration Portfolio Evaluation identifier). The MAP tag is requested during the connector setup phase. AWS Transform applies these tags during landing zone deployment.

Reversing changes

Only non-deployed elements can be removed. Once an OU or account is deployed, it cannot be removed through the landing zone agent.

When removing elements, order matters — you must remove children before parents:

  1. Remove accounts first (by email).

  2. Remove SCPs from OUs.

  3. Remove child OUs — an OU cannot be removed if it still has accounts or nested OUs.