AWS Organizations: A Multi-Account Strategy That Survives Year Two

Cloud Security

Single-account AWS estates do not scale past a handful of engineers. A deliberate OU layout, SCP hierarchy, and account vending pipeline keep governance intact while teams move fast.

By Arjun Raghavan, Security & Systems Lead, BIPI · February 4, 2024 · 7 min read

Every AWS estate we inherit started the same way. One root account, a dozen IAM users, and a Terraform state file someone hand-edited at 2am during an outage in 2021. Two years later it has 400 IAM roles, six different VPC CIDR overlaps, and a CloudTrail bill no one understands. AWS Organizations is the only escape hatch, and the difference between a clean Organization and a messy one is mostly decisions made in the first 90 days.

OU layout is a one-way door

Service Control Policies inherit down the OU tree. That means the shape of your OU tree determines the shape of your guardrails for the next five years. We default to four top-level OUs: Security, Infrastructure, Workloads, and Sandbox. Security holds the log archive and audit accounts. Infrastructure holds the network account and shared services. Workloads splits into Prod and NonProd sub-OUs. Sandbox is where developers learn AWS at $50 per month with a hard SCP cap.

The mistake we see most often is environment-first OU design (Prod OU, Dev OU, Staging OU at the top level). It breaks the moment you need a security-only SCP that applies everywhere. Function-first beats environment-first.

SCPs that actually deny things

Most Organizations we audit have one SCP attached to the root: FullAWSAccess. That is the default, and it does nothing. Useful SCPs we attach on day one:

• Deny leaving the Organization, removing the account from OU, or disabling CloudTrail in every account.
• Deny IAM user creation in Workloads OUs. SSO only.
• Deny use of regions outside ap-south-1 and us-east-1 (or wherever the business actually operates).
• Deny root user actions except billing in member accounts.
• Deny disabling GuardDuty, Security Hub, or Config recorder.

SCPs are deny-only filters layered on top of IAM permissions. They do not grant anything. The common failure mode is writing an SCP with a Condition that looks right but never matches because the API call does not include that context key. Test every SCP in a sandbox OU before promoting it.

Account vending or you will drown

By account 30, manually creating accounts through the console is a full-time job. We build account vending pipelines using either Control Tower's Account Factory or a custom Terraform module that calls the organizations:CreateAccount API. The pipeline handles: account creation, OU placement, baseline VPC (or no VPC if Transit Gateway shared), CloudTrail trail, GuardDuty enrollment, Config aggregator, default IAM Identity Center permission sets, and a break-glass IAM role with a 30-day expiry.

Control Tower is fine for organizations under 100 accounts that do not need much customization. Past that, the rigidity of Control Tower's mandatory controls becomes a problem and teams move to Account Factory for Terraform (AFT) or a fully custom module.

IAM Identity Center as the front door

Identity Center (the service formerly known as AWS SSO) is the only way to do cross-account access that does not turn into a nightmare. Federate to Okta or Azure AD upstream. Define permission sets centrally. Assign permission sets to AD groups against AWS accounts. Engineers get a single console URL and a single aws sso login command for CLI work.

Permission sets we standardize on: ReadOnly, PowerUser (no IAM), Admin (break-glass, MFA-required), and BillingViewer. Custom permission sets per service team get created on request but expire after 90 days unless renewed. That single rule kills 80% of permission sprawl.

What we wish we had done earlier

Three patterns we keep retrofitting into existing Organizations: a dedicated network account that owns the Transit Gateway and centralized egress; a delegated administrator pattern so the security team can manage GuardDuty and Security Hub from the audit account without touching the management account; and tag policies enforced at the OU level so cost allocation actually works.

The management account should run nothing. No workloads, no IAM users, no Terraform state. Treat it as a billing and Organizations control plane. If someone has admin access to the management account they have admin access to every account in the Organization, which is exactly the blast radius we are trying to avoid.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.