Organizations, OUs, and Service Control Policies

Goal

Build on the account-boundary mental model by showing how AWS organizes many accounts into a governable structure.

The previous section argued that accounts are architecture boundaries. This section explains how AWS Organizations, organizational units, and service control policies help a company manage those boundaries as a single estate instead of a loose pile of separate accounts.

The Short Version

AWS Organizations gives structure to a multi-account environment. Organizational units group accounts that should share governance or delegation patterns, and service control policies define the outer limit of what member accounts are allowed to do.

The durable idea is:

AWS hierarchy works when each level answers a different question: which accounts belong together, who governs them, and which actions should never be allowed.

The Three Layers To Keep Straight

Many teams get confused because these concepts sound administrative. They are easier to use when each one has one clear job.

That division matters because the hierarchy is not meant to duplicate IAM. IAM still decides what a user or role is allowed to do inside an account. SCPs decide what should never become available in that account, even if someone later grants an IAM permission.

A Practical Hierarchy

The hierarchy usually looks something like this:

Organization root
  -> Security OU
  -> Infrastructure OU
  -> Production OU
  -> Non-production OU
  -> Sandbox OU
      -> Accounts

The names vary. The important question is whether the grouping tells a useful control story.

For example:

• Production accounts may need tighter region restrictions and stronger change guardrails.

• Sandbox accounts may allow experimentation but still block risky actions such as disabling core logging.

• Security-related accounts may need separation from general shared-platform functions.

If an OU does not help you explain a difference in control, delegation, or lifecycle, it may not be a useful OU.

What AWS Organizations Adds

Without AWS Organizations, a company can still create many AWS accounts. What it lacks is a clean way to manage them as one governed environment.

AWS Organizations adds several practical benefits:

• Central grouping of accounts into a hierarchy.

• Central policy attachment across multiple accounts.

• Consolidated billing visibility.

• Account creation and service integration as part of one estate.

• Delegation patterns for supported central services.

This is why Organizations is more than a convenience feature. It gives the multi-account model an operating spine.

What SCPs Actually Do

SCPs are one of the most misunderstood AWS governance tools.

An SCP does not grant access. It does not replace IAM. It does not tell a user what they can do in detail. Instead, it sets a maximum boundary for what IAM in that member account can ever allow.

That distinction is the whole point.

IAM says:
  "This role is allowed to do X."

SCP says:
  "In this account or OU, X is never allowed."

In effective-permission terms, the result is the intersection of the IAM permissions and the SCP boundary. If IAM allows an action but the SCP denies it, the action is blocked.

This makes SCPs useful for high-confidence guardrails such as:

• Preventing use of unwanted AWS Regions.

• Blocking changes to critical security services.

• Restricting sensitive account-level actions to approved paths.

• Keeping sandbox accounts away from capabilities that create governance risk.

How To Design OUs Well

A common first instinct is to mirror the org chart. That sometimes helps, but it is rarely enough.

A better starting point is to organize OUs around differences in:

• Control strictness.

• Environment type.

• Business or regulatory isolation.

• Delegated operating model.

• Lifecycle patterns.

For instance, production and sandbox often belong in different OUs even if the same team owns both. The reason is not departmental structure. The reason is that the acceptable risk and allowed actions are different.

Example: One Enterprise, Two Control Patterns

Imagine an enterprise with application teams that need freedom in development accounts but tighter discipline in production.

The platform team creates:

• A Sandbox OU with broad experimentation rights but with core guardrails still preserved.

• A Production OU with stronger restrictions on regions, logging, and certain administrative changes.

• A Security OU for central evidence and response accounts.

The teams still use IAM roles inside each account. They still use pipelines and workload-specific permissions. But the organization hierarchy makes sure the overall risk posture is different in the right places before any one role is created.

That is the value of the hierarchy: it turns policy intent into inherited structure.

Trade-Offs

Common Mistakes

• Treating SCPs as permission grants. They only define the maximum boundary; IAM still has to grant the actual permissions.

• Designing OUs only from the org chart. Useful OUs reflect control and lifecycle patterns, not just reporting lines.

• Applying root-level SCPs without testing. Broad mistakes at the top of the tree can break many accounts at once.

• Attaching guardrails with no risk story. Every SCP should reduce a named risk, not exist because "governance wanted more policies."

If Someone Asks You

If someone asks, "What are OUs and SCPs actually doing in an AWS estate?" a clear answer is:

AWS Organizations groups accounts into a managed hierarchy. OUs collect accounts that need similar control patterns, and SCPs define the outer permission guardrails for those member accounts. IAM still grants the detailed access inside each account.

What You Should Remember

Organizations define the estate, OUs group responsibility, and SCPs draw the outer boundary of allowed behavior.

The most important idea is this:

A good AWS hierarchy does not just sort accounts. It explains how control differs across the estate.

Questions to Check Your Understanding

1. What problem does AWS Organizations solve beyond simply having many separate accounts?

2. Why are production and sandbox accounts often placed in different OUs?

3. Why do SCPs still require IAM policies to be useful?

Further Study

• What is AWS Organizations? - Official AWS overview of account grouping, central governance, and consolidated management.

• Service control policies (SCPs) - Official AWS explanation of SCP behavior, limits, and testing guidance.