AWS Control Tower Setup: Automated Landing Zone for Multi-Account AWS

AWS Control Tower is AWS's managed landing zone service — it creates and maintains a multi-account AWS environment with security guardrails, account vending, and baseline configuration already in place. For organizations starting a new multi-account deployment, Control Tower dramatically reduces the time to a production-ready organization structure compared to building the same configuration from scratch.

Understanding what Control Tower does and doesn't do is essential before deploying it. Control Tower is opinionated about some decisions (your OU structure, your foundational accounts) and extensible for others (custom guardrails, additional account customizations). Knowing where the edges are prevents surprises after deployment.

What Control Tower Creates

During setup, Control Tower creates several resources automatically:

Foundational accounts: Log Archive account (centralized CloudTrail and Config log storage) and Audit account (read-only access to all member accounts for security tooling). These are created by Control Tower and you should not use them for other purposes.

Organizational Units: Security OU (containing the Log Archive and Audit accounts), Sandbox OU (for experimental workloads), and the Root OU. You can add additional OUs after setup.

Baseline guardrails: A set of SCPs and Config rules that implement AWS security best practices. These are categorized as "mandatory" (always enabled) or "strongly recommended" (enabled by default, can be disabled). The mandatory guardrails prevent actions like disabling CloudTrail, disabling Config, and altering the Log Archive bucket.

Account Factory: A Service Catalog product that provisions new accounts with your baseline configuration applied. Account Factory is the primary day-to-day interface for Control Tower — when you need a new AWS account, you use Account Factory rather than the Organizations console.

AWS SSO (Identity Center) setup: Control Tower configures IAM Identity Center for centralized access to all accounts in your organization. This includes pre-configured permission sets (administrator access, read-only access) that can be assigned to users or groups.

Account Factory Configuration

Account Factory allows you to pre-configure settings for all accounts created through it: home region, allowed regions, pre-provisioned organizational units, and email patterns. Configure these before onboarding teams to Control Tower.

For email addresses (required to be unique per account), use email aliases or the + addressing feature of services like Google Workspace. A pattern like aws-account-{accountname}@yourcompany.com creates unique addresses without requiring separate email accounts. Route all these aliases to a shared mailbox that your infrastructure team monitors for AWS account-level notifications (billing alerts, security notices, SES/AUP notices).

Account Factory for Terraform (AFT) is an extension that replaces the Service Catalog interface with a Terraform-based vending machine. AFT uses a Git repository to define account requests — to create a new account, submit a pull request. AFT then provisions the account, applies customizations defined in the AFT customizations repository, and enrolls it in Control Tower. This approach provides complete Infrastructure-as-Code treatment for account provisioning and is the recommended path for organizations with existing Terraform expertise.

Extending Control Tower with Customizations

Control Tower's baseline guardrails don't cover everything. Extend it with:

Custom SCPs: Attach additional SCPs to OUs through the Organizations console or AFT customizations. Control Tower-managed SCPs should not be modified directly — make changes through Control Tower or add supplemental SCPs that work alongside the managed ones.

CloudFormation StackSets: Deploy additional baseline resources to all accounts using CloudFormation StackSets. Common additions: budget alerts, additional Config rules, specific IAM roles for security tooling, GuardDuty additional configuration. StackSets applied at the organization root deploy to all accounts automatically when new accounts are enrolled.

AWS Config custom rules: Add custom Config rules beyond the built-in guardrails. These can enforce organization-specific policies that aren't covered by AWS managed rules — required tagging patterns, approved AMI lists, specific security group configurations.

Control Tower Limitations

Control Tower has meaningful constraints to understand before committing:

Control Tower creates resources in your accounts that it manages. If you modify or delete these resources outside Control Tower, you'll get "drift" that Control Tower flags and needs to repair. Work with Control Tower's interfaces rather than directly modifying managed resources.

Control Tower supports specific home regions. Not all AWS regions are supported as Control Tower home regions. You can still use other regions for workloads, but Control Tower's management infrastructure runs in the supported region.

Existing organizations can be enrolled in Control Tower ("landing zone enrollment"), but the process requires care. Control Tower will create the Log Archive and Audit accounts (if they don't exist), configure the required OUs, and apply guardrails to existing accounts. Test this process in a non-production organization structure before migrating your production environment.

Day-to-Day Operations

After setup, Control Tower operations center on a few regular activities: enrolling new accounts through Account Factory, reviewing the Control Tower dashboard for drift and guardrail violations, and updating Control Tower when new versions are released (Control Tower provides periodic updates that add new guardrails and features).

Monitor the Control Tower management account's CloudTrail for Organization-level actions. Any account creation, OU changes, or SCP modifications appear here. These events should be low-frequency and should match your change management records — unexpected Organization changes are worth investigating.

Related Reading

• AWS Organizations best practices — organizational structure that Control Tower builds on
• Service Control Policies — the guardrail mechanism Control Tower uses
• Organizational Unit structure — OU design within your Control Tower deployment
• Multi-account monitoring — observability across a Control Tower-managed environment

FAQ

Should I use Control Tower or build my own landing zone?

For most organizations, Control Tower is the right choice. It implements AWS best practices out of the box and reduces time-to-productive considerably. Building your own landing zone from scratch is justified when you have specific requirements that Control Tower's opinionated design conflicts with, or when your team has deep AWS Organizations and Terraform expertise and prefers full control over every configuration decision. For teams without this expertise, a custom landing zone built under time pressure tends to miss important security baselines.

Can I use Control Tower with an existing AWS Organization?

Yes, but the enrollment process requires preparation. You need to ensure your existing Organization's management account, email addresses, and OU structure are compatible with Control Tower's requirements. AWS provides pre-enrollment checks that identify potential issues. The most common blocker is the management account having workloads that should be moved before enrollment, or email addresses that don't meet Control Tower's format requirements.

How do I handle Control Tower drift?

Control Tower drift occurs when resources it manages are modified outside of Control Tower. The Control Tower dashboard flags drifted accounts and shows what changed. Repair drift through the "Re-register OU" or "Re-register account" options in Control Tower, which re-applies the managed baseline. Prevent drift by training your team to use Control Tower interfaces rather than directly modifying Organizations, SCPs, or managed Config rules.