AWS OUs are governance scopes, not folders

An AWS organisation begins to accumulate accounts.

The console presents them in a tree.

Someone creates branches that look familiar:

Engineering

Security

Finance

Data

Marketing

The structure is tidy.

It resembles the company chart.

Everyone can find their department.

Then the organisation attaches policies.

Production accounts need stricter controls than development.

Security accounts need authority that ordinary workloads must not receive.

Sandbox accounts need cost and service restrictions.

Policy changes need somewhere safe to produce their first consequences.

The decorative folder tree has become a control tree without being designed as one.

AWS calls these groupings organisational units, usually shortened to OUs. An OU groups accounts so they can be administered together. Accounts beneath it receive applicable policies attached to that OU and its ancestors.

An OU is a governance scope: it groups account boundaries that should receive the same inherited controls and operational treatment.

The hierarchy is visually useful.

Its architecture lives in what it causes accounts to inherit.

Accounts are boundaries; OUs govern them

An AWS account contains resources, identities, quotas, cost and operational consequences.

An OU does not contain VPCs, clusters or databases directly.

It contains:

accounts
child OUs
policy attachments
organisational metadata

ORGANISATIONAL UNIT
        │
        ├── Account A
        │      └── AWS resources
        │
        ├── Account B
        │      └── AWS resources
        │
        └── Child OU
               └── Account C
                      └── AWS resources

The distinction is:

ACCOUNT BOUNDARY

Which resources, identities,
data, cost and failures
share one administrative fate?


OU GOVERNANCE SCOPE

Which account boundaries
should receive common
controls and treatment?

An OU does not create:

network isolation
IAM isolation
quota separation
billing separation
data separation

Accounts provide those boundaries.

OUs organise and apply governance to them.

Accounts contain consequences. OUs group accounts whose consequences should be governed in the same way.

Give every OU a control contract

An OU should have more than a name and a collection of policy documents.

It should have an operating contract.

ou:
  name: Production
  purpose: govern customer-facing workload accounts
  owner: platform-governance
  last_reviewed: 2026-01-10

eligible_accounts:
  - production application accounts
  - production data-service accounts

required_characteristics:
  - customer or operational data
  - availability commitments
  - tested recovery obligations
  - restricted production authority

control_families:
  authorization:
    - approved-region-scp
    - protect-security-services-scp
  service_configuration:
    - production-configuration-baseline
  operational:
    - production-backup-policy
    - production-tag-policy

entry_requirements:
  - central logging verified
  - backup registration verified
  - production access model approved
  - service owner recorded

exit_requirements:
  - replacement governance scope identified
  - inherited-policy impact reviewed
  - critical journeys retested

exceptions:
  owner: platform-governance
  expiry_required: true

The contract answers:

why the OU exists
which accounts belong there
which controls apply
what must be true before entry
what must be checked before exit
how exceptions are governed
who owns the model

A useful placement question is:

Would moving this account here
make the OU contract
more true or less true?

A good OU description sounds like an operating contract.

A weak one sounds like a filing label.

Policy families inherit differently

An account receives policies attached directly to it and applicable policies along its path through parent OUs to the root.

That does not mean every policy family follows one generic evaluation model.

ORGANISATION ROOT
       │
       ▼
PARENT OU
       │
       ▼
CHILD OU
       │
       ▼
ACCOUNT

The path defines scope.

The policy type defines evaluation.

Authorization policies

AWS Organizations has two authorization-policy types:

service control policies
resource control policies

An SCP bounds the maximum permissions available to principals in affected member accounts.

An RCP bounds the maximum permissions that supported resources may accept.

Neither grants access.

AUTHORIZATION POLICY PATH

root guardrails
      │
      ▼
parent OU guardrails
      │
      ▼
child OU guardrails
      │
      ▼
account guardrails
      │
      ▼
request must survive
every applicable constraint

An explicit deny at an applicable level cannot be repaired by granting AdministratorAccess inside the account.

The effective permission still depends on other controls such as IAM policies, resource policies, permissions boundaries, session policies, key policies and service-specific behaviour.

Declarative and management policies

Declarative and other management-policy families use policy-specific inheritance and merging rules.

Depending on the policy type, lower scopes may:

replace inherited values
append values
inherit locked values
refine an effective configuration

DECLARATIVE POLICY PATH

root configuration
       │
       ▼
OU refinements
       │
       ▼
account refinements
       │
       ▼
merged effective configuration

The organisation should know:

which policy family is attached
how that family inherits
which values descendants may change
how the effective policy is inspected
which service behaviour changes when the policy applies

An OU does not apply one generic kind of inheritance. It scopes policy families whose evaluation and merging behaviour must be understood separately.

This distinction prevents a clean hierarchy diagram from hiding very different control semantics.

Design OUs around common treatment

The company chart answers:

Who reports to whom?

The OU hierarchy should answer:

Which accounts require
the same governance treatment?

Those answers may occasionally produce similar groupings.

They should not be assumed to be identical.

Teams reorganise.

Platform engineering moves.

Security reporting lines change.

Products merge or split.

If the OU tree mirrors those changes, every reorganisation creates pressure to move accounts and therefore change policy inheritance.

TEAM REORGANISATION
        │
        ▼
OU REORGANISATION
        │
        ▼
ACCOUNT MOVEMENT
        │
        ▼
CONTROL CHANGE

Ownership belongs in:

account metadata
service catalogues
contacts
documentation
cost allocation

The OU tree should remain focused on stable control requirements.

Useful governance scopes may include:

Security

Infrastructure

NonProduction

Production

Sandbox

PolicyStaging

Suspended

These names describe treatment or operating state.

Names such as:

TeamA

ProjectPhoenix

MariamAccounts

Miscellaneous

say little about inherited controls.

A person viewing:

Workloads / Production / bfstore-prod

should be unsurprised by the policies that account receives.

Moving an account is a control migration

An account can move from the root into an OU, between OUs or back to the root.

Its ID and resources remain the same.

Its inherited control environment changes.

MOVE ACCOUNT
      │
      ▼
CHANGE PARENT
      │
      ▼
CHANGE POLICY PATH
      │
      ▼
CHANGE EFFECTIVE CONTROL

Treat the move as a control migration.

PROPOSE MOVE
      │
      ▼
COMPARE SOURCE AND TARGET CONTRACTS
      │
      ▼
IDENTIFY POLICY CHANGES
      │
      ▼
TEST CRITICAL OPERATIONS
      │
      ▼
MOVE ACCOUNT
      │
      ▼
VERIFY EFFECTIVE CONTROLS
      │
      ▼
MONITOR FOR REGRESSION

Before the move

Review:

policies lost from the old path
policies gained from the new path
direct account attachments
automation and role assumption
logging and backup
delegated-service behaviour
emergency access
effective service configuration

After the move

Verify:

expected deployments still work
prohibited actions remain denied
logs continue to arrive
backups continue to execute
security services remain enabled
declarative configurations match the target contract
the service catalogue reflects the new treatment

Define rollback criteria as well.

Moving an account back restores its former inheritance path.

It does not guarantee that every operational consequence created under the temporary policy environment has been reversed.

Dragging an account between branches can have considerably more consequence than dragging a file between folders.

Stage governance changes against representative systems

An organisation policy can have a large blast radius.

A mistaken control may block:

deployments
backups
logging
incident response
service-linked operations
account administration

A staged rollout should separate three kinds of evidence.

POLICY AUTHORING

syntax
static analysis
policy review


POLICY CONFORMANCE

expected actions allowed
expected actions denied


OPERATIONAL COMPATIBILITY

delivery
logging
backup
security
recovery

The workflow becomes:

AUTHOR POLICY
      │
      ▼
STATIC VALIDATION
      │
      ▼
POLICY-STAGING OU
      │
      ▼
REPRESENTATIVE NON-PRODUCTION ACCOUNTS
      │
      ▼
PRODUCTION TARGET
      │
      ▼
BROADER SCOPE

A useful policy-test account should contain representative:

automation roles
logging integrations
backup paths
service-linked roles
emergency-access mechanisms
resources
permitted and prohibited journeys

EMPTY POLICY TEST

policy attaches successfully

REPRESENTATIVE POLICY TEST

real operating journeys
continue or fail as intended

The PolicyStaging OU is not where a test account happens to be stored.

It is the controlled first blast radius for governance changes.

Its location expresses a rollout strategy.

Keep exceptions explicit

Once OUs are understood as governance scopes, a temptation appears:

one unusual account

therefore

one new OU

This produces categories such as:

ProductionExceptLoggingRule

TemporaryMigration

SandboxWithDatabasePermission

LegacySpecialCase

An OU is useful when it represents a stable management category.

A temporary difference should normally remain visibly temporary.

Direct account attachments

AWS allows policies to be attached directly to an account.

That can be appropriate.

It also creates divergence that is not obvious from the visible OU tree.

OU POLICY

part of the visible
governance category


DIRECT ACCOUNT POLICY

explicit divergence
from that category

Every direct attachment should appear in an exception register.

exception:
  account: bfstore-prod
  policy: temporary-migration-access
  reason: database migration
  owner: platform-data
  approved: 2026-01-20
  expires: 2026-02-15
  removal_condition: migration-complete

Prefer OU-level policy for stable shared treatment.

Use direct attachments for explicit, documented exceptions.

Otherwise:

VISIBLE TREE

and

ACTUAL CONTROL MODEL

become different systems.

Turning every exception into architecture allows it to grow roots.

Keep the hierarchy explainable

Nested OUs allow broad controls higher in the tree and narrower controls lower down.

Workloads
└── Production
    └── Regulated

Nesting can express a real refinement.

It can also create a policy maze.

An operator investigating a denied action may need to inspect:

root policies
parent OUs
child OUs
direct account policies
IAM policies
resource policies

The issue is not whether AWS technically permits another level.

It is whether a person can determine effective control without performing organisational archaeology.

A useful hierarchy should make these facts clear:

why this OU exists

which accounts are eligible

which controls it adds

which exceptions exist

who owns the contract

A flatter, comprehensible tree is usually stronger than a deep hierarchy whose inherited behaviour nobody can confidently explain.

Two bfstore governance scopes

The bfstore organisation does not need another complete account inventory to explain OU design.

Two contracts demonstrate the model.

Production OU

ou:
  path: Workloads/Production
  purpose: govern customer-facing workload accounts

eligible_accounts:
  - bfstore-prod
  - future production workload accounts

controls:
  - approved Regions
  - protected security configuration
  - restricted production authority
  - production backup requirements
  - production service configuration

entry_tests:
  - logging delivery
  - backup registration
  - temporary operator access
  - deployment workflow
  - recovery ownership

exceptions:
  expiry_required: true

The OU exists because its accounts share production consequence and operating treatment.

PolicyStaging OU

ou:
  path: Lifecycle/PolicyStaging
  purpose: contain the first consequences of governance changes

eligible_accounts:
  - representative policy-test accounts
  - selected non-production canaries

controls:
  - policies under evaluation
  - baseline organisation protections

required_evidence:
  - allowed-action tests
  - denied-action tests
  - logging continuity
  - backup continuity
  - delegated-administration compatibility
  - emergency-access compatibility

promotion:
  owner: platform-governance
  requires_review: true

This OU exists because its accounts share a rollout state, not a product or department.

The visible position and the control purpose agree.

Questions I now ask

Purpose

Which stable control requirement
justifies this OU?

Eligibility

Which accounts are allowed
to enter it?

Policy families

Which authorization and
configuration policies apply?

Divergence

Which direct attachments or exceptions
make accounts differ?

Movement

What changes when an account
enters or leaves?

Testing

How are policy conformance
and operational compatibility tested?

Explainability

Can an operator explain
the effective control path?

Meaning

Does the OU name describe
its governance treatment?

These questions turn the hierarchy from a directory into an operating model.

The mental model I am keeping

My earlier model was:

ORGANISATIONAL UNIT

a folder used to keep
AWS accounts tidy

The stronger model is:

                         ORGANISATION ROOT
                                  │
                                  ▼
                         SHARED BASELINE
                                  │
              ┌───────────────────┼───────────────────┐
              │                   │                   │
              ▼                   ▼                   ▼
           SECURITY         INFRASTRUCTURE        WORKLOADS
              │                   │                   │
              ▼                   ▼           ┌───────┴───────┐
       GOVERNANCE SCOPE     GOVERNANCE SCOPE   │               │
                                               ▼               ▼
                                        NON-PRODUCTION     PRODUCTION
                                               │               │
                                               ▼               ▼
                                          ACCOUNT SETS    ACCOUNT SETS

Accounts answer:

Which resources and authority
share an administrative fate?

OUs answer:

Which accounts should receive
the same governance treatment?

Policy families answer:

How does each control
evaluate or merge?

Policy staging answers:

Where should a new control
produce its first consequences?

Account movement answers:

Which control contract
should govern this account now?

And exception management answers:

Where does reality diverge
from the visible hierarchy?

OUs are visually presented as branches and folders.

That presentation is convenient.

It is not their most important property.

An OU is a statement that the account boundaries beneath it should be governed together.

Its name should describe a stable treatment.

Its contract should explain that treatment.

Its policies should implement it.

Its entry and exit tests should verify it.

The account tree may still look beautifully organised.

That should be the side effect.

The architecture lives in what the tree causes to be inherited.