AWS Control Tower 4.0: A New Look at Landing Zones

Source: Dev.to

Overview

AWS Control Tower has long been the go‑to solution for implementing governance based on AWS best practices, though it can be a controversial topic among SREs and Platform Engineers. With the release of Landing Zone 4.0, Control Tower takes a step forward, giving more flexibility in managing accounts and Organizational Units (OUs). This makes both greenfield and brownfield deployments easier to adopt and operate. Overall, it’s a positive development for AWS Control Tower, even though some challenges and areas for improvement still remain.

Note: This blog post focuses on the direction AWS Control Tower is heading, rather than the specifics of the 4.0 release.

Context & Motivation

• Ideally, both 3.3 and 4.0 would have been available for new deployments for a longer overlap period.
• AWS Control Tower aims to support deployments via APIs, but the rollout highlighted that a more structured release process isn’t fully in place yet, which caught many users by surprise.

Major Enhancements in Control Tower 4.0

1. Shift to an AWS Organizations‑Centric Model

• Before 4.0:

  • Control Tower required you to specify the name of a security OU during deployment.
  • Control Tower created that OU and managed all accounts inside it.

• Now (4.0):

  • You can leverage pre‑existing OUs directly in Control Tower.
  • Organizations retain control over their OU structure, can integrate existing hierarchies, and keep their naming conventions and internal governance practices.

Why this matters:

• Particularly advantageous for brownfield deployments where multi‑account best practices already exist.
• Existing OUs and accounts can be seamlessly integrated without restructuring around the traditional Control Tower manifest and Account Factory model.

2. Auto‑Enrollment Capabilities

• What it does:

  • When an account is moved into an OU registered with Control Tower (using the Control Tower Baseline), it is automatically enrolled and provisioned with required resources.

• Benefits:

  • Eliminates manual workflows or one‑off processes for applying guardrails.
  • Baseline security, logging, and compliance controls are enforced from day one, reducing configuration drift.
  • Simplifies governance as environments grow (new accounts, mergers, acquisitions).

• How to use:

  1. Move an AWS account into a Control Tower‑registered OU → it is auto‑enrolled.
  2. To unenroll, move the account into an OU not registered in AWS Control Tower.

Note: Auto‑enrollment is also available in Landing Zone 3.3. You do not need to upgrade to 4.0 to start using it—just enable it in your Control Tower settings.

Warning: Auto‑enrollment is an asynchronous process. When moving accounts in the web console, give Control Tower time to process the enrollment/unenrollment. It isn’t perfect yet, but it’s improving—be patient.

3. Reduced Dependence on Account Factory

• With auto‑enrollment and the ability to register/reregister entire OUs, Control Tower no longer requires every AWS account to be provisioned through Account Factory.
• This removes the need to manage Service Catalog products for each account, simplifying the workflow.

Note: AWS Config is still required to be created by Control Tower. If you move accounts into Control Tower, ensure they do not already have Config set up.

4. More Natural Workflow via AWS Organizations

Note: Automation teams still need to consider Service Catalog portfolio access when registering/reregistering OUs. Even if Account Factory isn’t used, Control Tower performs a permission check on the IAM role/user to validate access to the Service Catalog portfolio.

• This approach enables the use of CloudFormation StackSets, EventBridge rules, and other services tied to AWS Organizations to deploy and manage resources across multiple accounts, making multi‑account setups smoother and less manual.

Changes to the Setup Process

1. Pre‑staging of Organization resources is now required before deployment.
2. Logging architecture has changed:
   • Landing Zone 4.0 uses two separate buckets in the Log Archive account—one for CloudTrail and another for AWS Config.
   • Earlier versions (3.3 and below) used a single bucket.
   • Customers must update any tools or pipelines that reference logs to account for this split.
   • The original bucket continues to be used for CloudTrail.

Final Thoughts

These enhancements mark a continued shift in operational philosophy toward account vending. By embracing auto‑enrollment and OU registration, Control Tower offers greater flexibility while reducing reliance on Service Catalog and Account Factory.

While the changes bring many benefits, they also introduce new considerations (pre‑staging resources, split logging buckets, permission checks). Understanding and planning for these will help you get the most out of AWS Control Tower 4.0 and future releases.

Upgrade Overview

Upgrading from Control Tower 3.3 to 4.0 is generally smooth if you consider all the changes listed below. The process can take time because several asynchronous operations must complete, so plan for potential delays in provisioning and enrollment tasks.

Key Changes

• IAM Role Update

  • The AWSControlTowerCloudTrailRole now uses an AWS‑managed policy instead of an inline policy.
  • Even if the permissions are identical, the role will fail if the managed policy isn’t attached.

• Manifest Structure

  • Control Tower introduced a new data structure for the manifest file.
  • The manifest is now optional.
  • When using the API to update, you must review the manifest and remap existing configurations to the new structure.

• Logging Changes

  • Logging is now split into two separate objects in the manifest.
  • CloudTrail retains the old bucket in the log‑archive account during an upgrade.
  • AWS Config receives a new, separate bucket in the log‑archive account.

• Organizational Unit (OU) Assumptions

  • You no longer specify the name of a Security OU to create.
  • It is assumed that both the log‑archive and audit accounts exist in the same OU.

• AWS Config Aggregator

  • The aggregator is set up using trusted delegation for AWS Organizations.

• Baseline Versioning

  • After upgrading, many baselines move from version 4.0 to 5.0, which can be confusing.
  • You may need to update your baselines accordingly.

• API‑Driven Upgrade

  • The upgrade process is fully supported via the Control Tower API, reducing complexity and saving time when orchestrating upgrades, enrollment, and provisioning tasks programmatically.
  • When using the API, ensure you review and remap the manifest to the new structure.

Benefits of Control Tower 4.0

• Greater flexibility in OU and account structure.
• Easier integration for brownfield deployments.
• Improved alignment with native AWS Organizations features.
• Enhanced operational and security automation through:
  • StackSets
  • EventBridge
  • Controls Catalog
  • Other organization‑targeted services

Don’t get me wrong—there were some issues with the rollout and a few bumps still need smoothing out, but overall, Control Tower 4.0 is heading in the right direction.

Additional Resources

• More details on the changes can be found here. (Replace # with the actual link.)