DEV Community

AWS Community Builders profile image George Rolston
George Rolston for AWS Community Builders

Posted on

AWS Control Tower 4.0: A New Look at Landing Zones

#aws

AWS Control Tower has long been the preferred 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.

I want to preface this by saying that this blog post focuses on the direction AWS Control Tower is heading, rather than the specifics of the 4.0 release. Ideally, I wish there would have been a longer period where both 3.3 and 4.0 were available for new deployments. From what I understand, 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.

Native OU and Account Management

One of the biggest enhancements in Control Tower 4.0 is the shift from a rigid, Control Tower-managed model to a more native AWS Organizations-centric approach. Previously, setting up Control Tower required specifying the name of the security OU during deployment, and Control Tower would create it and manage all accounts in it.

Now, instead of being forced to have Control Tower create the security OU, you can leverage pre-existing OUs directly into Control Tower. This allows organizations to retain control over their OU structure, integrate existing organizational hierarchies, and better align with their naming conventions and internal governance practices.

This change is particularly advantageous for brownfield deployments, where customers have already implemented multi-account best practices. Existing OUs and accounts can now be seamlessly integrated into Control Tower without the need to restructure everything around the traditional Control Tower manifest and Account Factory model.

Auto-Enrollment: Flexibility Meets Automation

Control Tower 4.0 also takes advantage of the relatively new auto-enrollment capabilities. With auto-enrollment, accounts moved into an OU registered with Control Tower using the Control Tower Baseline are automatically enrolled and provisioned with required resources. By automatically enrolling accounts into Control Tower as they are created or detected within AWS Organizations, teams no longer need to rely on manual workflows or one-off processes to apply guardrails. This ensures that baseline security, logging, and compliance controls are consistently enforced from day one, reducing the risk of configuration drift or unmanaged accounts operating outside of governance boundaries. All that is required is you move an AWS Account into a Control Towered registered OU. To unenroll, simply move the account into an OU that is not registered in AWS Control Tower.

Note: Auto-enrollment is also available in Control Tower Landing Zone 3.3. You do not need to upgrade your Landing Zone to 4.0 to start using. Simply go into the setting of your Control Tower Landing Zone and enable it.

Auto enrollment also helps organizations keep up as their environments grow. Whether adding new accounts through expansion, mergers, or acquisitions, auto enrollment makes it easier to maintain governance without piling on extra administrative work. Platform teams can spend less time managing account lifecycles, and security or compliance teams get better visibility into which accounts meet organizational standards. Overall, it helps make a multi-account AWS environment more consistent and easier to manage, even if it’s not a perfect solution.

Warning: Auto enrollment is an asynchronous process. When moving accounts in the web console give time for Control Tower to successfully process the enrollment/unenrollment of the AWS account. It is not perfect, but it is getting better…be patient.

Account Factory Not Required

These changes mark a continued shift in operational philosophy to account vending. With auto enrollment and ability to register/reregister entire OUs, Control Tower no longer requires for individual AWS accounts to be provisioned through Account Factory. In my opinion this is great as I no longer have to worry about Service Catalog products and all the troubles that can be associated with that.

Note: AWS Config is still required to be created by Control Tower. So if you are moving accounts into AWS Control Tower, you will need to ensure they do not have Config already set up.

Instead Control Tower appears to be embracing a more natural workflow via AWS Organizations:

  • Accounts can be created natively in AWS Organizations.
  • They can be moved into the appropriate OUs registered in AWS Control Tower.
  • Once in the OU, accounts are automatically enrolled and resources are provisioned according to Control Tower guardrails and baselines.

Note: Automation teams still need to consider Service Catalog portfolio access during register/reregistering OUs. Even if Account Factory is not used for the AWS accounts in the OU, Control Tower still does a permission check on the IAM role/user to validate they have access to the Service Catalog portfolio.

This approach lets organizations use CloudFormation StackSets, EventBridge rules, and other services tied to AWS Organizations to deploy and manage resources across multiple accounts. It helps make multi-account setups a bit smoother and easier to keep in check, without all the manual work.

Changes in Control Tower Setup with LZ 4.0

While these enhancements bring greater flexibility, they do introduce some changes to the setup process:

  • Pre-staging of Organization resources is now required prior to deployment.
  • Logging architecture has changed: LZ 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 will need to ensure that tools and pipelines referencing logs are updated to account for this split. The original bucket continues to be used for CloudTrail, so existing operations can remain intact.
  • The role AWSControlTowerCloudTrailRole uses an IAM AWS managed policy now instead of an inline policy. Even if permissions are exactly the same, you will encounter issues with this role if the managed policy isn’t attached.
  • Control Tower has an updated data structure for the manifest file
    • Logging is now broken out into two different objects in the manifest
      • CloudTrail will retain the old bucket in the log archive account if you are upgrading
      • Config will get a new separate bucket in the log archive account.
  • You no longer give the name of security Organization Unit to create; instead it is assumed that both the log archive and audit accounts will exist in one OU.
  • AWS Config aggregator is setup and it uses trusted delegation for AWS Organizations
  • The manifest is optional.
  • After upgrading from 3.3 to 4.0, you may need to update your baselines. For most baseline versions, the version went from 4.0 to 5.0 which is confusing to say the least.

More details on changes can be found here.

Upgrade Process

Upgrading from Control Tower 3.3 to 4.0 is generally smooth if you consider all the changes from above. Though it can take time as several asynchronous operations complete. Planning for potential delays in provisioning and enrollment tasks is recommended.

The upgrade process is fully supported through API, which can significantly reduce complexity and save time when orchestrating upgrades, enrollment, and provisioning tasks programmatically. However, when using the API to update, you will need to review the Control Tower manifest and remap some of the current configurations to the new structure.

Conclusion

Control Tower 4.0 seems to be heading in a better direction for managing multi-account governance, working more closely with the native features of AWS Organizations. By enabling pre-existing OU imports, auto-enrollment, and a more natural account provisioning workflow, organizations gain:

  • Greater flexibility in OU and account structure
  • Easier integration for brownfield deployments
  • Alignment and enhanced operational and security automation through StackSets, EventBridge, Controls Catalog, and 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.

Top comments (0)