Rafagross

Posted on Sep 27 Originally published at rafael-gross.com

AWS Organizations in Production: Structure, SCP Evaluation, and Landing Zone Gotchas

#aws #cloud #devops #security

Most teams adopt AWS Organizations for consolidated billing and stop there. The real value is the control plane: a tree of accounts where guardrails attached at the top apply to everything below. That same tree is also where most "why is this denied?" tickets come from, because the evaluation rules are less intuitive than IAM alone.

This post covers the structure, how policies are evaluated, and the gotchas worth knowing before you run it in production.

The Account Is the Boundary

An AWS account is the hard boundary for resources, security, and billing. IAM manages identities inside an account. Organizations manages the accounts themselves.

That distinction drives the whole multi-account model: separate accounts give you blast-radius isolation, clean cost attribution, and a place to attach controls that no one inside the account can override.

Structure

An organization has:

One management account. It owns the organization and is the payer account. It should run org and billing tasks only. No workloads.
One root. The top of the tree. Policies attached here apply to every account.
Organizational units (OUs). Containers for accounts. OUs can nest up to five levels deep under the root.
Member accounts. Where workloads, logging, and security tooling live.
Policies. Attached at the root, an OU, or an individual account.

A common baseline layout:

OU	Accounts	Purpose
Security	Log Archive, Security Tooling (Audit)	Centralized logs, delegated admin for security services
Infrastructure	Network, Shared Services	Transit, DNS, shared tooling
Workloads	Prod, NonProd	Application accounts, grouped by lifecycle
Sandbox	Per-developer or per-team	Experimentation with looser controls
Suspended	Accounts pending closure	Deny-all quarantine

Tip: Design OUs around the controls and lifecycle you want to apply, not around the org chart. Teams get reorganized; "prod needs stricter guardrails than sandbox" does not change.

Enable All Features

Organizations has two feature sets. Consolidated-billing mode only merges invoices. All features adds the authorization policies (SCPs, RCPs), management policies (tag, backup, EC2), trusted access for service integrations, and delegated administrators. If you are building a landing zone, you need all features.

Policy Types That Matter Day to Day

Policy	What it does
SCP (service control policy)	Sets the maximum permissions for IAM users and roles in member accounts. Grants nothing on its own.
RCP (resource control policy)	Sets the maximum permissions on resources in member accounts (S3, KMS, Secrets Manager, SQS, and many more), regardless of who is calling. Grants nothing on its own.
Tag policy	Standardizes tag keys and values so cost allocation and ABAC stay consistent.
Backup policy	Deploys AWS Backup plans centrally across accounts and Regions.
EC2 policy (declarative)	Enforces EC2, VPC, and EBS baselines org-wide, such as IMDS defaults, AMI and EBS snapshot block public access, serial console access, and VPC Block Public Access. The configuration is maintained even as the service adds new APIs.

How Inheritance Actually Works

This is the part that trips people up.

A Deny is simple: attach it anywhere and it applies to everything below that point.

An Allow is not inherited the way people expect. For an action to be permitted in an account, an SCP must allow it at every level from the root down to the account: the root, each OU in the path, and the account itself. If any level is missing the Allow, the action is implicitly denied, even if an IAM policy in the account grants *:*.

Root            FullAWSAccess        -> allows *
  OU Workloads  AllowOnlyApprovedSvc -> allows ec2:*, s3:*, ... (no dynamodb:*)
    Prod acct   FullAWSAccess        -> allows *

Result in Prod: dynamodb:* is denied. The OU level never allowed it.

This is why the default FullAWSAccess SCP exists at every level. If you replace it with an allow-list at the OU, that allow-list becomes the ceiling for every account underneath.

Most common SCP incident: Someone detaches FullAWSAccess from an OU while testing an allow-list SCP, and every account under that OU loses access to services that weren't on the list. Prefer deny-list SCPs (explicit Deny statements on top of FullAWSAccess) unless you have a specific reason to allow-list.

How a Request Is Evaluated

For a principal in a member account, access requires an Allow from every applicable layer:

Identity-based policy on the user or role must allow the action.
SCPs in the account's path must allow it.
RCPs in the path must allow it for the target resource (if the service supports RCPs).
Permission boundaries, session policies, and resource-based policies still apply as usual.

An explicit Deny at any layer wins. SCPs and RCPs only ever reduce what is possible; they never grant access.

A practical consequence: when you debug an AccessDenied in a member account and the IAM policy looks correct, check the SCPs on every node in the account's path, not just the ones attached directly to the account.

Landing Zone Pattern

The goal is to separate the governance plane from workloads:

Management account: org and billing only. Tightly restricted human access.
Security OU: Log Archive receives org-wide CloudTrail and Config data. Security Tooling (Control Tower calls it Audit) is the delegated administrator for GuardDuty, Security Hub, and similar services.
Infrastructure OU: networking and shared services.
Workloads OU: prod and non-prod split so guardrails can differ.

AWS Control Tower orchestrates this on top of Organizations: Account Factory for provisioning, managed controls (preventive via SCPs/RCPs, detective via AWS Config, proactive via CloudFormation hooks), and drift detection. If you manage infrastructure as code, Account Factory for Terraform (AFT) provisions accounts through a Terraform pipeline.

Operating Lifecycle

Identity: IAM Identity Center for human access, cross-account roles for automation, least privilege throughout.
Provisioning: Account Factory, AFT, or the Organizations API. Never click-ops accounts in production.
Baseline: logging, Config, security services, and networking applied from day one, typically via StackSets or Control Tower.
Guardrails: preventive, detective, and proactive controls, plus drift detection.
Lifecycle: move accounts between OUs as their purpose changes. To retire one, move it to a Suspended OU with a deny-all SCP, then close it. A closed account can be reopened during the post-closure period (90 days).

Production Gotchas

SCPs and RCPs never restrict the management account. Anything you run there is outside your guardrails. That is the main reason to keep workloads out of it.
SCPs don't affect service-linked roles. AWS services acting through service-linked roles are not limited by your SCPs.
SCPs do apply to delegated administrator accounts. They are member accounts. Make sure your guardrails don't block the security services you delegated.
OUs nest at most five levels deep. Deep hierarchies are also harder to reason about during an incident. Keep it shallow.
Delegate security services to the Audit/Security Tooling account instead of administering them from the management account.
Limits: SCP documents max out at 10,240 characters, and each root, OU, or account can have up to 10 SCPs attached. Plan statement consolidation early.

Quick Inventory Commands

# Root ID and enabled policy types
aws organizations list-roots

# All accounts in the org
aws organizations list-accounts

# OUs under a parent (root or OU)
aws organizations list-organizational-units-for-parent --parent-id r-examplerootid

# SCPs attached to a specific target
aws organizations list-policies-for-target \
  --target-id 123456789012 \
  --filter SERVICE_CONTROL_POLICY

Run these from the management account or a delegated administrator.

DEV Community