I'm interested in learning how different organizations manage their AWS multi-account environments at scale.

Hello.

The following document provides useful information on best practices for designing OUs in AWS Organizations.
I have also designed OUs for customer AWS accounts in the past, and I used this document as a reference for that work.
By building on AWS Organizations, AWS Control Tower, and IAM Identity Center, we can centrally manage services like Security Hub, GuardDuty, Config, and CloudTrail through Organizations integration; I believe this has made operations much easier.
https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_ous_best_practices.html

The AWS Control Tower documentation is also a useful reference.
It is explained that using OUs is recommended for AWS accounts used for development or for common infrastructure.
Since AWS Control Tower is an orchestration service that builds and governs a landing zone by integrating components like AWS Organizations and IAM Identity Center, starting with Control Tower—absent any specific requirements—makes it easier to reduce operational overhead compared to building a custom landing zone from scratch.
https://docs.aws.amazon.com/controltower/latest/userguide/aws-multi-account-landing-zone.html

Agree with the Control Tower approach. I would also suggest keeping the OU structure simple rather than creating too many OUs. Security, Shared Services, Prod, Non-Prod and Sandbox is usually a good starting point, and SCPs can then be applied at the OU level.

IAM Identity Center also helps a lot once the number of accounts grows. Using groups and permission sets is much easier than managing IAM access separately in every account.

For logging/security, I would centralize CloudTrail, Config, GuardDuty and Security Hub using dedicated security/log archive accounts. And for new accounts, Control Tower Account Factory/AFT with Terraform can automate most of the baseline setup.

The main thing is to make account creation repeatable. A new account should already have the required access, logging, security controls and tags instead of configuring all of that manually afterward.

Good question, and one where the real complexity tends to show up after you've read the docs.

The Control Tower + IAM Identity Center + Organizations stack that was mentioned is the right foundation, but there are a few design decisions that are easy to get wrong and expensive to undo.

On OU structure: the two default OUs Control Tower deploys (Security and Sandbox) are a starting point, not a finished design. Most organizations eventually need Infrastructure, Workloads_Prod/Non-Prod, PolicyStaging, and Suspended OUs on top. The progression matters because SCPs and guardrails attach at the OU level, so getting the hierarchy wrong early means retrofitting them later across enrolled accounts.

On security service delegation: each service (GuardDuty, Security Hub, Config, Macie, Detective) needs its own delegated admin designation, all typically pointing at the same Security Tooling account. Control Tower handles some of this automatically but leaves several services unconfigured post-setup. Missing this step means your security findings are fragmented across accounts instead of centralized.

On account provisioning automation: there are three official IaC patterns on top of Control Tower. Account Factory for Terraform (AFT) if your team lives in Terraform, Customizations for Control Tower (CfCT) if you prefer CloudFormation/SCPs, and Landing Zone Accelerator (LZA) if you have formal compliance requirements like SOC 2 or PCI-DSS. Choosing the wrong one for your toolchain creates friction your team carries permanently.

Two questions that would most change which of these patterns makes sense for your situation: do you already have accounts enrolled in AWS Organizations, and does your team have a preferred IaC tool today?

I do AWS architecture advisory work with a focus on exactly this kind of governance design. Happy to share more detail if any of this is useful.