AWS Landing Zone: OU Structure & Account Baselines — Security/Infrastructure/Workloads/Sandbox OUs, Account Factory Baselines & Environment Separation

In a nutshell

If AWS Organizations is an apartment building, then every AWS account is a separate apartment: a fire in one can’t spread to the others (that is your blast radius), each has its own electricity meter (billing) and its own fuse rating (service quotas), and the locks are completely independent (IAM). An organizational unit (OU) is a floor of that building. A house rule you pin to a floor — a Service Control Policy (SCP) — automatically applies to every apartment on that floor and every floor beneath it, and, crucially, it can only ever forbid things, never hand out new privileges. This lesson is about drawing the floor plan: which apartments share a floor, what house rules hang on each floor, and what “starter furniture” (the baseline) every new apartment comes with on move-in day.

The one idea to carry through everything below: you group accounts by the guardrails they should share, not by which team or department rents them. Two production accounts that must obey the same rules belong on the same floor even if different teams own them; a team’s dev and prod accounts belong on different floors even though one team owns both. Teams reorganize constantly; guardrails and blast radius are stable. So the tree is built from policy and isolation, and ownership is carried by tags and by the account boundary itself.

Why should a beginner care? This OU tree is the load-bearing wall of the whole landing zone. Control Tower controls, Config conformance packs, IAM Identity Center permission sets, backup policies, and your billing rollups all attach to it. Design it well and governance “snaps on” at the right altitude with almost no per-account toil; design it badly and every later decision inherits the debt.

Level: Advanced · Time: ~40 min

Before you start, you should be comfortable with:

• What an AWS account, an IAM user, and an IAM role are — and that IAM is where permissions are actually granted (an SCP can only take away).
• What AWS Organizations and a management (payer) account are — see AWS Landing Zone: Multi-Account & AWS Organizations.
• How a landing zone is stood up with AWS Control Tower — see AWS Landing Zone: AWS Control Tower.

After this lesson you will be able to:

• Lay out the AWS-recommended OU hierarchy (Security, Infrastructure, Workloads → Prod/Test/Dev, Sandbox, Policy Staging, Suspended) and justify every branch instead of copying it on faith.
• Explain why the account — not the VPC and not a tag — is AWS’s strongest isolation, billing, and quota boundary.
• Trace an SCP as it is inherited and intersected down the OU tree, and predict an account’s effective permissions.
• Decide when a workload deserves its own account (the account-per-team / per-environment / per-application call).
• Describe what a new account inherits automatically the moment it is vended, and how a baseline is kept from drifting.
• Map your target tree onto the OUs Control Tower actually creates for you versus the ones you build yourself.

Where this fits

This is part 3 of AWS Landing Zone & Control Tower. Part 1 established the multi-account strategy and the management account; part 2 stood up the landing zone with AWS Control Tower, the Security and Log Archive accounts, and the baseline log/audit plumbing. This part decides the shape of the organization: the organizational unit (OU) hierarchy that Service Control Policies (SCPs), the AWS Control Tower controls (formerly “guardrails”), and centralized config hang off; the per-account baseline that every account inherits the moment it is vended; and the environment separation model that keeps dev, test, and prod in different blast-radius zones. OUs and account baselines are the load-bearing wall — Control Tower controls, Config conformance packs, IAM Identity Center permission sets, and your billing rollups all attach to this tree. Get the tree wrong and every later workstream inherits the debt; get it right and governance “snaps on” at the correct altitude with almost no per-account toil.

The recommended OU structure

What an OU actually is

An organizational unit in AWS Organizations is a container inside the organization root that groups AWS accounts so you can apply policy to many accounts at once through inheritance. The policy types that flow down an OU branch are Service Control Policies (the IAM permission ceiling — they never grant, only constrain the maximum available permissions), Resource Control Policies (RCPs) (a maximum-permission ceiling on resources, e.g. forcing aws:SecureTransport on every S3 bucket and SQS queue org-wide), Tag Policies, Backup Policies, and Declarative Policies for EC2/EBS/VPC. AWS Control Tower additionally attaches its controls at the OU level — preventive controls are implemented as SCPs, detective controls as AWS Config rules, and proactive controls as AWS CloudFormation Hooks.

Three hard rules shape every design decision:

• You can nest OUs up to five levels deep below the root, but depth is what bites you — every level multiplies the SCP evaluation you must reason about, and Control Tower’s own enrollment and drift detection get harder to follow.
• An account lives in exactly one OU at a time. Moving it re-evaluates the entire inherited policy set instantly, which is the mechanism behind the “Suspended” pattern below.
• SCPs are deny-biased and intersect down the branch. A child OU can only add restriction; it can never weaken a parent’s Deny. An explicit Deny anywhere on the path wins. This is exactly why you group accounts by the guardrails they should share, not by org chart or geography.

The single most important framing: an OU is a unit of policy, not a unit of ownership. The mistake juniors make is modeling the company’s departments as OUs. The mistake architects make is modeling blast radius and shared controls as OUs and letting tags, not the tree, carry ownership.

The reference hierarchy (AWS SRA / Control Tower aligned)

The AWS Security Reference Architecture (SRA) and the Control Tower defaults converge on an opinionated, flat-ish, function-first tree. Under the organization root you create:

Root  (AWS Organizations management account governs this)
├── Security                 (Control Tower mandatory; Audit + Log Archive live here)
│   ├── [Audit account]      (cross-account security read/respond; delegated admin)
│   └── [Log Archive account](immutable CloudTrail + Config S3, central log bucket)
├── Infrastructure           (shared platform services every workload consumes)
│   ├── [Network account]    (Transit Gateway, central VPCs, Route 53 Resolver, NFW)
│   └── [Shared Services]    (CI/CD, AMI/golden images, central ECR, IPAM, directory)
├── Workloads                (where application teams' accounts live)
│   ├── Prod                 (production accounts, tightest controls)
│   ├── Test                 (pre-prod / staging accounts)
│   └── Dev                  (development / SDLC accounts)
├── Sandbox                  (loose guardrails, detached from the network, hard $ caps)
├── Policy Staging           (an empty OU to safely test new SCPs/controls before rollout)
└── Suspended                (quarantine: cancelled or compromised accounts, deny-all)

Why each top-level branch exists, and the representative guardrails that land there:

Security OU

This is the only OU AWS Control Tower mandates and pre-populates: when you set up the landing zone it creates the Security OU and provisions the Audit and Log Archive accounts into it. The Audit account is your cross-account security-operations seat — it holds the read/respond roles and is the natural delegated administrator for GuardDuty, Security Hub, Macie, Detective, IAM Access Analyzer, and Inspector, so security tooling runs out of the management account (a hard AWS best practice). The Log Archive account holds the central S3 bucket that receives organization CloudTrail and Config snapshots, ideally with S3 Object Lock (WORM) and a bucket policy that even the org admin cannot weaken without leaving a trace.

The SCPs here are the “never touch the evidence” set: deny cloudtrail:StopLogging, cloudtrail:DeleteTrail, config:DeleteConfigurationRecorder, config:StopConfigurationRecorder, and any s3:DeleteBucket/s3:PutBucketPolicy against the log bucket. You also deny organizations:LeaveOrganization here so a security account can never be detached from governance.

Infrastructure OU

The Infrastructure OU holds the shared platform plane — the things every workload account consumes but should never own. In a hub-and-spoke landing zone the Network account owns the Transit Gateway, the centralized inspection/egress VPC (often with AWS Network Firewall), Route 53 Resolver rules and inbound/outbound endpoints, and the RAM (Resource Access Manager) shares that hand subnets out to workload accounts via VPC sharing. A separate Shared Services account owns the CI/CD tooling, the central Amazon ECR registries, golden AMI/EC2 Image Builder pipelines, VPC IPAM pools, and any AWS Directory Service / AD Connector.

Why split networking out at all? Because the Transit Gateway and central route tables are the component whose misconfiguration takes down every connected account at once — it deserves its own account, its own change control, and its own tighter SCP set (deny modifying TGW route tables outside a pipeline role, deny RAM share deletion, require IMDSv2, region-lock).

Workloads OU and its environment sub-OUs

This is where the actual applications live, and it is the only branch you sub-divide by environment. The recommended pattern is Workloads → {Prod, Test, Dev}, with each application getting separate accounts per environment (more on why under “Environment separation”). Some large orgs add a second axis — e.g. Workloads/Prod/Regulated vs Workloads/Prod/Standard, or Workloads/Prod/SOX — to layer compliance-specific controls (PCI, HIPAA, SOX) on top of the environment baseline. Resist going deeper than that: two meaningful axes (environment × compliance class) is almost always enough, and each extra level is an extra SCP intersection to reason about.

Sandbox OU

The Sandbox OU exists so engineers can experiment without punching holes in production guardrails and without touching the corporate network. The defining characteristic is isolation: SCPs deny creating VPC peering/TGW attachments to corp networks, deny actions that could move prod data in, and AWS Budgets actions apply a hard spend cap that can auto-attach a restrictive policy when a threshold is breached. Sandbox accounts are deliberately cattle, not pets — vended quickly, recycled aggressively, and never trusted with anything that matters.

Policy Staging OU

The Policy Staging OU is the one most teams forget, and it is what separates a mature platform from a fragile one. Because an SCP Deny is absolute and applies instantly to every account in the branch, a bad SCP can lock out an entire production OU in one click. The Policy Staging OU is a near-empty OU containing one or two throwaway accounts that mirror the access patterns of a real workload account. You attach the candidate SCP or new Control Tower control here first, run a smoke test (deploy a representative stack, assume the app role, exercise the deny paths), confirm nothing legitimate breaks, then promote the policy to Workloads/Prod. It turns “we changed an SCP and took down prod” into a non-event.

Suspended OU

The Suspended (or Quarantine) OU is a two-job container. Job one: cancelled accounts awaiting the 90-day closure window sit here, locked down so nobody spins new resources up in them. Job two — the one that earns its keep — is incident response: when an account is compromised, the fastest containment is to move it into Suspended, where a single Deny * SCP (with a narrow break-glass allow for forensics roles) strips every inherited permission instantly without you having to unwind individual IAM changes the attacker may have made. Because OU membership re-evaluates policy immediately, this is the cleanest “big red button” AWS Organizations gives you.

Why not model by org chart, region, or business unit?

Worked example: how an SCP travels down the tree

The single most important mechanic to internalize is how a permission survives — or doesn’t — as it passes through every OU between the root and an account. Get this right and the whole tree stops feeling like guesswork.

The two-part rule. For any single API action (say s3:DeleteBucket) to be permitted by the SCP layer on an account, both of these must be true at the same time:

1. Every level from the organization root down to the account contains at least one SCP that allows the action. The allow-lists intersect — a level that fails to allow it removes it, no matter what the levels above said.
2. No level anywhere on that path denies the action. A single explicit Deny beats every Allow, at any depth.

AWS attaches a default policy called FullAWSAccess ("Effect": "Allow", "Action": "*") to the root, to every OU, and to every account. While that default is in place, rule 1 is satisfied automatically for everything — so in a normal Control Tower organization only your Deny statements do any work. That is the deny-list strategy, and it is what almost everyone runs.

Let’s trace a real branch. Suppose an account orders-prod lives at Root → Workloads → Prod. You attach this SCP at the Workloads OU (it should apply to dev, test, and prod alike):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyRootUserActions",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringLike": { "aws:PrincipalArn": "arn:aws:iam::*:root" }
      }
    },
    {
      "Sid": "RegionLock",
      "Effect": "Deny",
      "NotAction": [
        "iam:*", "organizations:*", "sts:*",
        "route53:*", "cloudfront:*", "support:*", "waf:*", "wafv2:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": ["us-east-1", "us-west-2"]
        }
      }
    }
  ]
}

Then, at the narrower Workloads/Prod OU, you attach a second SCP that only production should feel:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "NoIamUsersInProd",
      "Effect": "Deny",
      "Action": ["iam:CreateUser", "iam:CreateAccessKey"],
      "Resource": "*"
    },
    {
      "Sid": "ProtectBackupsAndLogs",
      "Effect": "Deny",
      "Action": [
        "backup:DeleteBackupVault",
        "backup:DeleteRecoveryPoint",
        "cloudtrail:StopLogging",
        "cloudtrail:DeleteTrail",
        "config:StopConfigurationRecorder"
      ],
      "Resource": "*"
    }
  ]
}

Now compute what orders-prod can do. Start from FullAWSAccess (allow everything) inherited at the root. Subtract, in order:

• the root user can do nothing (the DenyRootUserActions statement at Workloads);
• any action outside us-east-1/us-west-2 is blocked except the genuinely global services listed in NotAction (IAM, Organizations, STS, Route 53, CloudFront, Support, WAF), which have no meaningful Region and would break if Region-locked;
• on top of that, in prod specifically, nobody can create IAM users or access keys, and nobody — not even an admin — can delete a backup vault, delete a recovery point, or stop the audit trail.

Everything else remains available at the SCP layer. Two things about that word “available” trip people up. First, the SCP is only a ceiling. orders-prod can create an S3 bucket as far as SCPs are concerned, but a principal in the account still needs an IAM policy that actually grants s3:CreateBucket. SCP says “the most you may do”; IAM says “what you may do.” A permission has to clear both gates. Second, the same account sitting one floor up in Workloads/Dev would keep IAM-user creation and backup deletion, because the second SCP is attached only to Prod — the tree position, not the account, decides the ceiling.

The allow-list variant. Some regulated orgs run the opposite strategy: they detach FullAWSAccess from an OU and attach an SCP that explicitly Allows only an approved set of services (Allow ec2:*, s3:*, rds:*, …). This is stricter — the default is now “deny everything not on the list” — but it is far higher-maintenance, because rule 1 now bites: every child OU beneath it must also allow each service, or accounts there silently lose it. A common failure mode is enabling a brand-new AWS service that nobody added to the allow-list, and spending an afternoon confused about why the console throws AccessDenied even for an admin. Reach for allow-lists only where a compliance regime demands a closed service catalog; keep deny-lists everywhere else. Authoring, testing, and version-controlling these policies at scale is its own discipline — see AWS Landing Zone: Guardrails (SCPs & Controls).

Per-account baselines

What a baseline is

A per-account baseline is the set of resources, configuration, and guardrails that every account receives automatically at vend time and continuously thereafter, so that no account is ever “naked.” There are two complementary layers:

1. The Control Tower baseline applied at enrollment — what AWS sets up the moment the account joins an enrolled OU.
2. Your custom baseline — the org-specific resources and config you bolt on via Account Factory customizations, blueprints, or a post-provisioning pipeline (the Account Factory for Terraform / AFT pattern, or Customizations for Control Tower / CfCT using CloudFormation StackSets).

What Control Tower bakes in automatically

When an account is provisioned through Account Factory (Control Tower’s account-vending mechanism, surfaced through AWS Service Catalog) and enrolled into a governed OU, it inherits:

Crucially, you never create these by hand per account — they ride along with enrollment. The architect’s job is to (a) ensure new accounts are always vended into a governed OU, and (b) define the custom layer below.

The custom baseline you add

Beyond what Control Tower gives you, almost every enterprise layers on a standard set. The decision is how to deliver it consistently:

Account Factory, AFT, and Customizations for Control Tower

There are three account-vending postures, and choosing among them is a real architectural decision:

The non-negotiable principle across all three: the baseline is code, applied idempotently, and re-converged. Drift is detected (Config + Control Tower drift detection) and corrected (re-run AFT / re-deploy the StackSet), so an account that someone hand-edits snaps back to baseline. A baseline that exists only as a runbook is not a baseline.

Account-vending request as an artifact

The concrete artifact of this discipline is the account request itself — in AFT this is a small Terraform module instance (or in CfCT, an entry in a manifest) capturing: account name and email (a unique, deliverable address, usually a +-suffixed alias on a shared mailbox), the target OU, the owner/cost-center/environment tags, the SSO access (which permission sets, which groups), and any account-specific customization toggles (e.g. “this account gets a shared VPC subnet,” “this is a serverless-only account, no VPC”). That request is reviewed via pull request, which gives you an auditable history of why every account exists.

Worked example: what happens the second an account is vended

A baseline is easiest to understand as a timeline. Follow one account, orders-prod, from a pull request to a governed, furnished account:

1. A request as code. An engineer opens a PR adding one small module instance to the account-request repo (below). It names the account, its email, its target OU, its tags, and any per-account overlay. Review of that PR is the auditable answer to “why does this account exist?”
2. Merge triggers the pipeline. With Account Factory for Terraform (AFT), the merge kicks a pipeline that calls Account Factory (a Service Catalog product Control Tower owns). Organizations creates the account and moves it straight into Workloads/Prod — it is never parked in the root.
3. Control Tower enrollment fires. The moment the account lands in a governed OU, the Control Tower baseline attaches: the org CloudTrail begins delivering to Log Archive, an AWS Config recorder starts and ships to the aggregator, IAM Identity Center is wired so access is via permission sets (not IAM users), the mandatory preventive SCPs apply, and the AWSControlTowerExecution role is created for future StackSet runs.
4. Global customizations run. AFT then applies the layer every account gets: delete the default VPC in every Region, turn on EBS encryption-by-default, set account-level S3 Block Public Access, enforce IMDSv2, stamp an AWS Budgets ceiling with Cost Anomaly Detection, and auto-enable GuardDuty/Security Hub/Inspector/Macie through the Audit account as delegated admin.
5. Account-specific customizations run. Finally the overlay named in the request applies — here, a shared-VPC subnet handed over by RAM; for a serverless-only account it might be no VPC at all.
6. Drift is watched and re-converged. Config and Control Tower drift detection watch the account forever after. If someone hand-edits it, re-running AFT (or re-deploying the StackSet) snaps it back. A baseline that lives only in a runbook is not a baseline — it must be code that re-applies.

The request itself is deliberately small and declarative. This is the real shape of an AFT account-request module instance (identifiers are placeholders):

module "orders_prod" {
  source = "./modules/aft-account-request"

  control_tower_parameters = {
    AccountEmail              = "aws+orders-prod@example.com"   # unique, deliverable
    AccountName               = "orders-prod"
    ManagedOrganizationalUnit = "Workloads/Prod"                # the target OU path
    SSOUserEmail              = "cloud-platform@example.com"
    SSOUserFirstName          = "Orders"
    SSOUserLastName           = "Prod"
  }

  account_tags = {
    Environment        = "prod"
    Owner              = "team-orders"
    CostCenter         = "CC-4471"
    DataClassification = "confidential"
  }

  change_management_parameters = {
    change_requested_by = "jane.doe"
    change_reason       = "Vend prod account for Orders service (JIRA PLAT-1287)"
  }

  account_customizations_name = "shared-vpc-workload"   # which per-account overlay to apply
}

Notice there is no click-ops here and nowhere to fat-finger the OU: the ManagedOrganizationalUnit is text in a reviewed file. AFT’s mechanics — the request, global, and account customization repos and how they re-converge — are covered end to end in Account Factory for Terraform (AFT).

Naming and tagging conventions that keep the tree searchable

At three accounts you can hold everything in your head; at three hundred you cannot, and the only thing that saves you is a boring, mechanical convention decided before the first account is vended. Retro-fitting names and tags across a live org is miserable, so treat this as part of the OU design, not an afterthought.

Two rules make tags trustworthy rather than decorative. First, enforce the keys with a Tag Policy so a missing or misspelled key is caught, and activate them as cost allocation tags in the billing console or they never reach Cost Explorer. Second, the Environment tag and the OU placement must always agree — an account tagged prod sitting in Workloads/Dev is a governance bug, and a periodic Config rule (or an AFT post-check) that flags “Environment tag ≠ OU” catches exactly that drift before it hurts.

Environment separation

Why separate accounts per environment, not VPCs or tags

The single strongest isolation boundary AWS gives you is the account. Service quotas, IAM trust, billing, and — critically — blast radius all stop at the account line in a way they never do at a VPC or tag boundary. The principle the AWS multi-account strategy hammers is: isolate production workloads in their own accounts, and give each application its own set of accounts per environment. So a single app “Orders” gets orders-dev, orders-test, and orders-prod as three separate accounts, sitting in Workloads/Dev, Workloads/Test, and Workloads/Prod respectively.

Separate accounts also make the promotion story clean: a CI/CD pipeline in Shared Services assumes a deploy role into orders-dev, then orders-test, then orders-prod, with a manual approval gate before prod. Each environment can carry a different SCP set purely by living in a different OU — dev can be allowed to spin up cheap experiments that prod denies, and prod can deny the IAM-user creation and backup-vault-tampering that dev tolerates.

How environment separation maps onto the OU tree

Environment is expressed twice, on purpose, and both must agree:

1. Structurally, via OU placement: the account sits in Workloads/Prod vs /Test vs /Dev, which controls which SCPs and Control Tower controls it inherits.
2. Descriptively, via a mandatory Environment tag enforced by a Tag Policy, which controls cost allocation, automation behavior, and queryability.

The two must never disagree — an account tagged prod sitting in the Dev OU is a governance bug. A periodic Config rule (or an AFT post-check) that flags “Environment tag != OU” catches exactly this drift.

The promotion and connectivity model

Environment separation is not just about blocking — it is about controlled flow:

• Network: prod, test, and dev attach to different Transit Gateway route domains (or separate TGWs) so a dev box can never route to a prod database. Sandbox attaches to nothing corporate.
• Data: prod data classification (e.g. Confidential) is denied from being copied into dev by SCP/RCP on the data-store actions; dev uses synthetic or masked data.
• Identity: different Identity Center permission sets per OU — broad Developer access in Dev, tightly scoped ReadOnly + break-glass in Prod, with privileged prod access fronted by approval (e.g. a temporary-elevation workflow).
• Deploy: one pipeline, three stages, assuming environment-specific deploy roles, with the prod stage gated by a human approval and (often) a change-management ticket reference.

The account-per-X decision: team, environment, or application

“Should this get its own account?” is the question you will answer hundreds of times, so it helps to have a rule instead of a mood. There are three axes people split on — team, environment, and application — and they are not equal. Environment is non-negotiable; application is common; team is usually a tag, not a boundary; Region is never a primary split.

The arithmetic falls out of the first two rows. A company with A independent applications, each needing dev/test/prod, lands near A × 3 workload accounts, plus the foundational handful (management, Audit, Log Archive, Network, Shared Services). Nine applications is roughly 9 × 3 = 27… but real orgs share some non-prod, split some prod by compliance, and add sandboxes, so the true number is a range you manage, not a target you hit. The discipline is not “few accounts” or “many accounts” — it is that every account’s existence is justified by a reviewed request, and its position in the tree is chosen by which guardrails it should inherit.

Going deeper

Why the account is the real boundary (quotas, billing, blast radius)

Everyone repeats “the account is the strongest isolation boundary,” but it is worth knowing precisely what stops at that line, because it is what makes the multi-account model non-negotiable rather than aesthetic:

• Service quotas are per-account, per-Region. A runaway Lambda fan-out or a test that opens 50,000 ENIs exhausts that account’s quota and throttles that account’s workloads. Put dev and prod in one account and a dev mistake can quota-starve prod; separate them and the blast radius is physically capped at the account edge.
• Billing rolls up but is measured per-account. Every account is a first-class line in Cost Explorer and the Cost and Usage Report. Splitting by account gives you unarguable cost attribution — no tag-hygiene project can match “this account cost $X.” Reserved Instances and Savings Plans purchased in any member account are shared across the org’s accounts by the payer, so you don’t lose commitment discounts by splitting.
• IAM trust stops at the account. A * in an IAM policy is catastrophic within one account; it cannot reach into another account unless you deliberately created a cross-account role and someone can assume it. Cross-account access is explicit, named, and auditable — the opposite of the implicit blast radius inside a shared account.
• The root user is per-account. Every account has its own root user with its own credentials and its own MFA. That is a liability you manage (lock it down, hardware MFA, no access keys) — but it is contained: compromising one account’s root does not touch another’s.

The VPC and the tag simply do not offer any of these. A tag is a label an admin can ignore; a VPC still shares the account’s IAM, quotas, root user, and bill. That is the whole argument for accounts-per-environment in one paragraph.

The management account is special — keep it empty

The management (payer) account is not “account number one that happens to be in charge.” It is structurally different, and treating it like a normal account is one of the most dangerous mistakes in the whole design:

• SCPs do not apply to it. You cannot constrain the management account with a Service Control Policy — it is exempt by design. So any workload you run there runs with no SCP ceiling at all, which is precisely the environment you spent this whole lesson trying to eliminate.
• It holds the keys to the kingdom. It can create and close accounts, invite and remove members, and change the org’s policies. Its root user and its IAM principals are the highest-value target in your entire cloud estate.
• Therefore: it runs nothing. No workloads, no data, no pipelines, ideally no human day-to-day logins. Its jobs are billing consolidation and being the place Organizations and Control Tower are administered from. Everything else is delegated out.

That last word is the mechanism. Delegated administration lets a security service be administered from another account while the management account stays clean. GuardDuty, Security Hub, Macie, Detective, IAM Access Analyzer, Inspector, the Config aggregator, Firewall Manager, and even CloudFormation StackSets all support a delegated administrator — and the canonical target is the Audit account in the Security OU. Running these from the management account is a documented anti-pattern: it widens the blast radius of your single most sensitive account for no benefit.

How your tree maps onto Control Tower’s default OUs

A common source of confusion: the elegant SRA-aligned tree above is mostly something you build, not something Control Tower hands you. When you set up the Control Tower landing zone, it creates only a small, opinionated starting set; you add and register the rest.

The verbs that matter are register (tell Control Tower to govern an existing OU) and enroll (bring an existing account under governance). New accounts vended through Account Factory are enrolled automatically; older accounts you created before Control Tower must be enrolled explicitly. The management account, note, is never enrolled — it governs, it is not governed.

SCP evaluation, precisely (and what SCPs never touch)

Beyond the deny-vs-allow-list model, a few sharp edges separate people who think an SCP is applied from people who know it is:

• SCPs filter principals in member accounts only. They shape what IAM users and roles inside your org’s member accounts can do. They never apply to the management account, and they do not touch principals from outside your organization who reach a resource through a resource-based policy.
• Service-linked roles are exempt. Roles that AWS services create to operate on your behalf (autoscaling, Elastic Load Balancing, and friends) are not constrained by SCPs — so a Deny * in a quarantine OU stops your principals cold but does not necessarily freeze every last piece of AWS-managed automation. Plan incident response around that.
• NotAction with Deny is the workhorse and the footgun. The Region-lock pattern (Deny on everything except a NotAction list of global services) is powerful, but forgetting to except a global service there — for instance leaving cloudfront out — quietly breaks it org-wide. Test these against Policy Staging, never straight to prod.
• RCPs are the resource-side twin. Where an SCP caps what a principal may do, a Resource Control Policy caps what may be done to a resource (for example forcing aws:SecureTransport on every S3 bucket and SQS queue). Effective access on a resource is the intersection of identity policy, SCP, resource policy, and RCP — all four gates, all must allow.

Hard limits you design around

The tree has physical limits, and a good design stays comfortably inside them rather than discovering them in an outage:

• OU depth: five levels below the root. You almost never want more than two meaningful axes (environment × compliance). Depth multiplies the SCP intersection you must reason about and makes Control Tower drift unreadable.
• SCP size: 5,120 characters each (whitespace included), and at most 5 SCPs attached to any one root, OU, or account. Big region-locks and long deny lists hit this ceiling; the fix is to split across the five slots or tighten the JSON, not to nest deeper.
• Accounts and OUs are quota-limited. The default per-organization account quota is low and is raised through Service Quotas / a support request; AWS supports orgs with thousands of accounts. Plan the increase before a mass-vending exercise, not during it.
• Account closure is slow and sticky. A closed account sits recoverable for 90 days and cannot be immediately reused; crucially its email address is not freed for reuse during that window. This is exactly why the aws+<workload>-<env>@ alias convention matters — you never want to be blocked from re-vending because an address is in limbo.

Operating the tree at scale — moves, closures, and drift

Three operational realities finish the picture. Moving an account between OUs re-evaluates its entire inherited policy set instantly — this is not a slow migration, it is an atomic change, and it is the engine behind both promotion (nothing moves at promotion — you deploy into the standing prod account) and the quarantine pattern (move a compromised account into Suspended and its Deny * strips every permission in seconds). Closure follows the 90-day rule above and should route through the Suspended OU so nobody spins up new resources in an account on its way out. And drift is the quiet killer: an account someone hand-edited slowly diverges from its baseline until it is the one account that behaves differently in an incident. The whole point of delivering baselines as code (AFT/CfCT StackSets) plus Config and Control Tower drift detection is that drift is detected and re-converged, not discovered at 3 a.m.

Real-world enterprise scenario

Context. Meridian Cargo, a fictional mid-size logistics SaaS, runs a fleet-tracking and freight-booking platform. They have 9 product teams, roughly 60 microservices, a hard PCI-DSS obligation (they store cardholder data for freight payments), and a board mandate to “move to a governed multi-account model in one quarter.” They start from a sprawling two-account mess (one “everything-dev,” one “everything-prod”) with shared IAM, no central logging, and a $90k/month bill nobody can attribute.

The decisions, per sub-component.

OU structure. Their platform team stands up AWS Control Tower, accepting the mandated Security OU (Audit + Log Archive). They then create Infrastructure (Network + Shared Services accounts), Workloads with Prod / Test / Dev children, a Sandbox OU, a Policy Staging OU, and a Suspended OU. Because PCI is in scope, they split Workloads/Prod into Prod/PCI and Prod/Standard — a second axis — so the PCI accounts inherit an extra conformance pack and a tighter region allow-list (us-east-1, us-west-2 only) on top of the prod baseline. Final tree: 7 top-level OUs, one two-level split under Prod — never deeper. They explicitly reject the team-per-OU model their first draft had (it produced 9 near-identical OUs); ownership moves to a mandatory Owner tag plus the account itself.

Per-account baselines. They adopt Account Factory for Terraform (AFT) because they are already a Terraform shop. Every account request becomes a pull request. The global customization layer (applied to all accounts) deletes the default VPC in every Region, sets EBS encryption-by-default, turns on account-level S3 Block Public Access, enforces IMDSv2 via a Declarative Policy, wires VPC Flow Logs + CloudTrail to the central Log Archive bucket, auto-enables GuardDuty, Security Hub, Inspector, and Macie through the Audit account as delegated admin, and stamps an AWS Budgets ceiling with Cost Anomaly Detection. The account-specific layer attaches a shared-VPC subnet (via RAM) for accounts that need one, or no VPC at all for the 12 serverless-only accounts. PCI accounts additionally receive an AWS Config conformance pack mapped to the PCI-DSS controls and a backup plan with AWS Backup Vault Lock enabled.

Environment separation. Each of the 9 product teams gets three accounts per product (dev/test/prod), so “freight-booking” becomes freight-dev, freight-test, freight-prod. They end up with ~60 workload accounts plus the 4 foundational ones (management, audit, log-archive, network) and shared-services — about 66 accounts total. Dev attaches to a non-prod TGW route domain; prod to a prod-only domain; the two cannot route to each other. A single AWS CodePipeline in Shared Services promotes builds dev → test → prod, assuming an environment-specific deploy role at each stage, with a manual approval and a change ticket required before the prod stage. A Config rule flags any account whose Environment tag disagrees with its OU.

The artifacts they produce. An OU design diagram and decision record; an AFT repository with the global + per-account customization modules; ~66 account-request Terraform module instances under version control; the SCP set per OU (with the candidate-SCP workflow routed through Policy Staging); the PCI conformance pack and Tag Policy; and an Identity Center permission-set matrix mapping AD groups → permission sets → OUs.

The measurable outcome. Within the quarter: 100% of accounts enrolled in a governed OU with the baseline applied automatically; central CloudTrail/Config with zero accounts able to disable the audit plane (verified by attempting it from Policy Staging); PCI scope reduced to the 9 Prod/PCI accounts only, shrinking the audit surface; cost now attributable to a team and environment for every dollar (cost-allocation tags enforced by Tag Policy); and a live drill where a deliberately “compromised” test account was contained in under two minutes by moving it to the Suspended OU — the Deny * SCP stripped every permission instantly.

Deliverables & checklist

By the end of this phase you should have produced:

• An OU design document / decision record justifying every OU and explicitly rejecting org-chart/region/BU modeling.
• The live OU hierarchy in AWS Organizations: Security, Infrastructure, Workloads (→ Prod/Test/Dev, plus any compliance split), Sandbox, Policy Staging, Suspended.
• The Security OU confirmed as Control Tower-managed with Audit + Log Archive accounts and the “protect the audit plane” SCPs.
• A documented per-account baseline: what Control Tower bakes in, plus your custom layer (encryption defaults, BPA, GuardDuty/Security Hub/Inspector/Macie, IMDSv2, budgets, default roles, logging).
• An account-vending pipeline — Account Factory, AFT, or CfCT — with account requests as code/PRs and idempotent, drift-corrected customizations.
• An SCP set per OU plus a working Policy Staging promotion workflow for new SCPs/controls.
• Tag Policy enforcing Environment, Owner, CostCenter, DataClassification, and a check that the Environment tag matches OU placement.
• An environment-separation model: separate accounts per env per app, TGW route-domain isolation, environment-scoped deploy roles, and a gated promotion pipeline.
• An IAM Identity Center permission-set matrix mapping groups → permission sets → OUs.
• A tested quarantine runbook: move a compromised account to Suspended and confirm the deny-all takes effect.

Common pitfalls

• Modeling OUs on the org chart. Departments reorg; SCPs don’t follow people. You end up with many shallow, near-identical OUs and constant churn. Fix: group by shared guardrails (environment × compliance), carry ownership in tags and the account boundary.
• No Policy Staging OU. Teams attach a new SCP straight to Workloads/Prod, a Deny is broader than intended, and an entire production OU is locked out in one click. Fix: always promote candidate SCPs/controls through a Policy Staging OU against a mirror account first.
• Hand-built, un-reconverged baselines. Someone documents the baseline in a runbook and applies it manually, so accounts drift and “naked” accounts appear. Fix: deliver the baseline as code (AFT/CfCT StackSets), detect drift with Config + Control Tower, and re-converge automatically.
• One account with env tags instead of accounts per environment. Tags don’t stop an IAM blast radius, a runaway bill, or quota exhaustion crossing from dev into prod. Fix: separate accounts per environment, placed in the matching Workloads sub-OU.
• Over-nesting the tree. Five-level-deep hierarchies mirroring the company make SCP intersection and Control Tower drift unreadable. Fix: stay flat — two meaningful axes is the ceiling for almost everyone.
• Running security tooling from the management account. Centralizing GuardDuty/Security Hub/Config aggregation in the management account violates AWS guidance and widens its blast radius. Fix: delegate administration to the Audit account in the Security OU.
• Vending accounts outside a governed OU. An account created directly in the root (or an un-enrolled OU) inherits no baseline and becomes a shadow-IT liability. Fix: force all vending through the pipeline into an enrolled OU, and alert on any account landing in Root.

Practice challenges

Work these in order — they escalate from “place the accounts” to “design and contain.” Try each before opening the solution.

1. Place the accounts (beginner). You have five accounts: log-archive, network-hub, payments-prod, payments-dev, and a throwaway scp-test-01. Put each in the right OU of the recommended tree.

<details> <summary>Solution</summary>

log-archive → Security; network-hub → Infrastructure; payments-prod → Workloads/Prod; payments-dev → Workloads/Dev; scp-test-01 → Policy Staging.

Why: each account is placed by the guardrail set it should inherit — audit-plane protection, shared-platform change control, tight prod controls, looser dev controls, and a mirror account for testing policies before they touch prod. </details>

2. Pick the delegated admin (beginner). Your security team wants GuardDuty, Security Hub, and Macie run centrally. Which account should be the delegated administrator, and which account must not run them?

<details> <summary>Solution</summary>

Delegate administration to the Audit account (in the Security OU). The management (payer) account must not run them — centralizing security tooling there is an AWS anti-pattern that widens the blast radius of your most sensitive account and is exempt from SCPs anyway.

Why: delegated administration is exactly the mechanism that keeps the management account empty while still giving you org-wide, single-pane security. </details>

3. Write the “protect the audit plane” SCP (intermediate). Write an SCP, suitable for the Security OU, that prevents anyone from stopping CloudTrail, deleting a trail, or detaching an account from the organization.

<details> <summary>Solution</summary>

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ProtectAuditPlane",
      "Effect": "Deny",
      "Action": [
        "cloudtrail:StopLogging",
        "cloudtrail:DeleteTrail",
        "config:StopConfigurationRecorder",
        "config:DeleteConfigurationRecorder",
        "organizations:LeaveOrganization"
      ],
      "Resource": "*"
    }
  ]
}

Why: an explicit Deny beats every Allow, so even a full administrator in the account cannot disable the evidence trail or escape governance — the guarantee you want on the Security OU. </details>

4. Compute effective permissions (intermediate). FullAWSAccess is attached everywhere. The Workloads OU denies all actions outside us-east-1/us-west-2 (with global services excepted). Workloads/Prod additionally denies iam:CreateUser. An admin role in payments-prod calls iam:CreateUser and, separately, ec2:RunInstances in eu-west-1. What happens to each call, at the SCP layer?

<details> <summary>Solution</summary>

iam:CreateUser → denied by the Prod-level SCP. ec2:RunInstances in eu-west-1 → denied by the Workloads-level Region lock (EC2 is regional and not in the global NotAction exception).

Why: a permission must clear every level’s ceiling; a Deny at any depth on the path removes it regardless of the admin’s IAM policy — and being an administrator does not lift an SCP. </details>

5. Design a tree with a compliance axis (advanced). A SaaS company has 12 applications (each needs dev/test/prod), a PCI-DSS obligation for 3 of them, and 8 serverless-only accounts that need no VPC. Sketch the OU tree and say roughly how many accounts result — without exceeding two meaningful axes.

<details> <summary>Solution</summary>

Top-level: Security, Infrastructure, Workloads, Sandbox, Policy Staging, Suspended. Under Workloads: Dev, Test, Prod, and split Prod into Prod/PCI and Prod/Standard (the second axis — environment × compliance — and no deeper). Roughly 12 × 3 = 36 workload accounts plus ~5 foundational (management, Audit, Log Archive, Network, Shared Services) ≈ ~41. The serverless-only accounts get the no-VPC account customization; they don’t need their own OU — the VPC decision is a baseline overlay, not a tree branch.

Why: compliance earns a sub-OU because PCI accounts inherit an extra conformance pack and tighter Region lock; “serverless” does not, because it is a per-account baseline choice, not a different guardrail set. </details>

6. Contain a compromised account (advanced). An attacker has valid credentials in orders-dev and is creating IAM users and exfiltrating from S3. Give the fastest containment that does not require you to unwind every IAM change by hand, and name one thing it will not stop.

<details> <summary>Solution</summary>

Move the account into the Suspended OU, which carries a Deny * SCP (with a narrow break-glass allow for a forensics role). OU membership re-evaluates policy instantly, so every inherited permission for your principals is stripped in seconds — no per-IAM-change cleanup needed. What it will not stop: service-linked roles are exempt from SCPs, so AWS-managed automation the attacker may have leaned on isn’t necessarily frozen, and any resource-based grant to an external principal still needs separate revocation.

Why: the quarantine OU is AWS Organizations’ “big red button” precisely because moving an account is an atomic policy re-evaluation, not a slow migration. </details>

Common beginner mistakes

These are conceptual traps — wrong mental models a newcomer forms before the mechanics click. (They are distinct from the architecture-level pitfalls listed earlier; those are things experienced teams still get wrong at scale.)

• “An SCP grants permissions.” It never does. An SCP is a ceiling — the most an account is allowed to do. If an S3 action isn’t happening, an SCP that “allows” it changes nothing; you still need an IAM policy that actually grants it. Right model: IAM grants, SCP caps, and a permission has to clear both gates.
• “I’ll just remove FullAWSAccess, it looks scary.” Detach that default Allow * from an OU without attaching a replacement allow-list and you have just created a deny-by-default black hole: accounts beneath it lose everything, including admins. Right model: FullAWSAccess is the thing that makes the common deny-list strategy work — leave it unless you are deliberately running a maintained allow-list.
• “An account can live in two OUs.” It cannot — an account is in exactly one OU at a time. Right model: the single OU an account sits in fully determines the guardrails it inherits; if you want two policy sets to apply, they must both be on that one path from the root.
• “The management account is just my main account, I’ll run stuff there.” The management account is exempt from SCPs and holds the power to create and close accounts — running workloads there puts them beyond every guardrail you built. Right model: keep it empty, and delegate security tooling out to the Audit account.
• “Tags will keep dev and prod apart.” A tag is a label; it stops nothing. A fat-fingered * policy, a runaway bill, or a quota exhaustion in a tag-separated environment crosses straight into the other. Right model: the account is the isolation boundary — separate accounts per environment, placed in the matching sub-OU.
• “Control Tower builds the whole tree for me.” It builds the Security OU (with Audit + Log Archive) and a default Sandbox OU — that’s it. Infrastructure, Workloads and its environment children, Policy Staging, and Suspended are yours to create and register. Right model: Control Tower gives you a governed foundation to extend, not a finished org chart.
• “Moving an account to another OU is a risky migration.” Nothing moves — no data, no resources. It is an instant re-evaluation of inherited policy. Right model: that instantaneous re-evaluation is a feature you exploit for quarantine and for placing an account under the right controls.

Glossary

• AWS Organizations — the service that groups many AWS accounts under one management account, so you can apply policy and consolidate billing across all of them.
• Organization root — the top container of the org. Everything (OUs and accounts) hangs beneath it; not to be confused with the root user of an account.
• Organizational unit (OU) — a container inside the org that groups accounts so policy can be applied to many at once through inheritance. An account is in exactly one OU at a time.
• AWS account — the fundamental isolation unit: its own IAM, its own quotas, its own bill, its own root user. AWS’s strongest blast-radius boundary.
• Management (payer) account — the account that owns the organization. Exempt from SCPs, holds account-creation power, consolidates billing. Keep it empty of workloads.
• Member account — any account in the org other than the management account; these are governed by SCPs.
• Blast radius — the maximum scope of damage a failure or compromise can reach. The account boundary caps it; a tag or a VPC does not.
• Service Control Policy (SCP) — an organization policy that sets the maximum permissions (a ceiling) for principals in the accounts it applies to. It can only deny/limit, never grant.
• Resource Control Policy (RCP) — the resource-side twin of an SCP: a ceiling on what may be done to a resource (e.g. force TLS on every S3 bucket), org-wide.
• FullAWSAccess — the default SCP (Allow *) AWS attaches to the root, every OU, and every account; leaving it in place is what makes the deny-list strategy work.
• Deny-list vs allow-list — two SCP strategies. Deny-list keeps FullAWSAccess and adds Deny statements (common). Allow-list removes FullAWSAccess and explicitly allows only approved services (stricter, higher-maintenance).
• AWS Control Tower — AWS’s managed landing-zone service; sets up the Security OU, Audit and Log Archive accounts, the baseline audit plane, and vends accounts via Account Factory.
• Landing zone — the pre-built, governed multi-account foundation (OUs, core accounts, logging, guardrails) that new workloads land into.
• Account Factory — Control Tower’s account-vending mechanism (surfaced through AWS Service Catalog) that creates and enrolls a new account.
• AFT (Account Factory for Terraform) — a GitOps pipeline that vends accounts from Terraform, runs global + account-specific customizations, and re-converges drift.
• CfCT (Customizations for Control Tower) — the CloudFormation/StackSet equivalent: lifecycle-triggered templates layered onto Control Tower.
• Baseline — the resources, config, and guardrails every account receives automatically at vend time and continuously thereafter, so no account is ever “naked.”
• StackSet — a CloudFormation mechanism that deploys the same stack across many accounts/Regions; a common baseline-delivery tool.
• Enroll / register — enroll brings an existing account under Control Tower governance; register brings an existing OU under governance.
• Delegated administrator — an account (canonically Audit) authorized to administer an org-wide service (GuardDuty, Security Hub, Config aggregator, etc.) instead of the management account.
• Audit account — the Security-OU account that holds cross-account security roles and is the delegated admin for security tooling.
• Log Archive account — the Security-OU account that holds the immutable central S3 bucket for CloudTrail and Config, ideally WORM-locked.
• IAM Identity Center — AWS’s SSO service; grants human access to accounts via permission sets rather than long-lived IAM users.
• Control / guardrail — a Control Tower governance rule: preventive (an SCP), detective (a Config rule), or proactive (a CloudFormation Hook).
• Tag Policy — an organization policy that enforces which tag keys/values must exist, keeping cost-allocation and OU-vs-tag checks reliable.
• Conformance pack — a packaged collection of AWS Config rules (e.g. mapped to PCI-DSS) deployed as one unit.
• Break-glass role — a tightly controlled, audited emergency-access role used only when normal access paths are unavailable (e.g. forensics in a quarantined account).
• Policy Staging OU — a near-empty OU where a candidate SCP/control is tested against a mirror account before it is promoted to production.
• Suspended (Quarantine) OU — an OU carrying a Deny * SCP; moving a compromised or cancelled account into it strips inherited permissions instantly.
• Service quota — a per-account, per-Region limit (e.g. max ENIs). Because quotas stop at the account line, they are a core reason to split environments into separate accounts.
• Drift — divergence of an account from its intended baseline (usually from a manual change); detected by Config/Control Tower and re-converged by re-running the baseline code.
• Consolidated billing — the management account’s rollup of all member-account charges into one bill, with shared Reserved Instance / Savings Plan discounts across the org.

What’s next

Part 4 of AWS Landing Zone & Control Tower moves from the account/OU skeleton to the policy plane itself — authoring and operating Service Control Policies, Resource Control Policies, and Control Tower controls as code, including the proactive/preventive/detective control mix and how to manage them at scale.