Enterprise AWS Governance (2026): OU Taxonomy, Policy Layering, and Exception RFCs That Scale
Quick summary: Control Tower gets you an org; it does not tell you how many OUs you need or which policy type owns VPC public access. Since re:Invent 2024 you have four layers — SCP, RCP, declarative, and tag policies — and RCP coverage grew through Feb 2026 (DynamoDB). A composite 60-account enterprise cut exception SCP attachments from 14 ad-hoc to 3 time-boxed RFCs in two quarters by moving accounts out of "temporary" prod OUs.
Key Takeaways
- Control Tower gets you an org; it does not tell you how many OUs you need or which policy type owns VPC public access
- Since re:Invent 2024 you have four layers — SCP, RCP, declarative, and tag policies — and RCP coverage grew through Feb 2026 (DynamoDB)
- A composite 60-account enterprise cut exception SCP attachments from 14 ad-hoc to 3 time-boxed RFCs in two quarters by moving accounts out of "temporary" prod OUs
- AWS Control Tower can stand up a landing zone in an afternoon; most enterprise programs still argue about OU design a year later
- For RAM sharing, Route 53 Profiles, and RCP examples, see cross-account patterns beyond the landing zone
Table of Contents
AWS Control Tower can stand up a landing zone in an afternoon; most enterprise programs still argue about OU design a year later. The setup guide tells you how to enable guardrails — not how many organizational units you need, which policy type should block VPC public access, or what happens when a team needs a 30-day exception for a legacy integration. Since AWS re:Invent 2024 (November 2024) you are choosing among four org-level policy families — SCPs, RCPs (data perimeter), declarative policies (durable EC2/VPC/EBS config — GA December 2024, including Control Tower managed declarative controls), and tag policies — with RCP service coverage still expanding through June 2025 (ECR, OpenSearch Serverless), January 2026 (Cognito, CloudWatch Logs), and February 2026 (DynamoDB).
This post is the governance operating model layer: OU taxonomy, policy layering, exception RFCs, and rollout order. For RAM sharing, Route 53 Profiles, and RCP examples, see cross-account patterns beyond the landing zone. We ship an OU taxonomy template, policy layering matrix, and governance exception RFC template.
Benchmark pattern (not a cited client) — Composite enterprise, ~60 workload accounts, Control Tower enabled, but 14 accounts carried one-off SCP detaches or lived in a “temporary prod” OU with no exit date. Security review found partner S3 access silently broken on 2 accounts after an overly broad RCP trial. After adopting OU taxonomy + RFC process: 3 active time-boxed exceptions, all with calendar revert; partner integrations tested in NonProd OU before root RCP promotion. The win is auditability and fewer permanent holes — not a headline cost save.
OU taxonomy: policy boundaries, not org charts
Copy and adapt the OU taxonomy template. Principles:
- Security OU — log archive, audit, security tooling; highest policy intensity; no application workloads.
- Infrastructure OU — network hub (Transit Gateway, egress), shared CI/CD, DNS; RAM shares originate here.
- Sandbox OU — individual accounts with spend caps and short lifetimes.
- Workloads OU — split NonProd and Prod; optionally Tier-1 vs Tier-2 prod for different RCP/SCP strictness.
- Exceptions OU — time-boxed only; every account has an
exit_bydate.
Opinionated take: if two OUs have identical SCP + RCP + declarative attachments, merge them. If HIPAA prod and general prod need different data perimeters, split. Never create an OU per microservice team — that is CloudFormation stack logic, not governance.
New accounts land in Sandbox or NonProd, never directly in Prod.
Policy layering: four tools, four jobs
Use the policy layering decision matrix. Short version:
| Job | Tool | Common mistake |
|---|---|---|
| Cap what your identities can do | SCP | Using SCP to simulate VPC config (brittle per API) |
| Cap what anyone can do to your resources | RCP | SCP-only data perimeter (external principal + bucket policy) |
| Enforce config end state (e.g. VPC BPA) | Declarative policy | SCP deny on one disable API |
| Require cost/security tags | Tag policy | SCP (cannot enforce all tag values on create) |
| Detect drift after deploy | AWS Config | Expecting SCP to fix existing misconfig |
Attach broad → narrow: root/security SCPs → workload OU SCP + RCP → declarative baselines → tag policies → resource policies.
This matches the SCP/RCP/declarative definitions in the cross-account post — we do not duplicate mechanism tutorials here.
Control Tower mapping
Control Tower classifies controls as preventive (SCP, RCP, declarative), detective (Config), and proactive (CloudFormation hooks). Your OU taxonomy should say which categories attach at which OU — e.g. all declarative VPC BPA controls on Workloads OUs, not Sandbox (developers need public test endpoints in isolated sandboxes with SCP spend caps instead).
Exception RFCs: time-boxed or it did not happen
Permanent policy changes go through normal change management. Temporary relief uses the governance exception RFC template:
- Max 90 days unless CISO extends
- Exception SCP attached only to Exceptions OU or named account
- Compensating controls documented
- Calendar auto-revert — not “we will remember”
What broke — A platform team detached a region-deny SCP from the entire Prod OU for one account’s legacy DR test — and forgot to reattach. Three weeks later, a developer provisioned non-approved region resources in a different prod account; Config caught it, but SCP was not there to prevent create. Fix: narrow exception moved to Exceptions OU on one account ID, RFC with end date, CloudTrail alert on
CreateVpcin unapproved regions. OU-wide detach for one account is never acceptable.
Rollout order (lockout-safe)
Same discipline as RCP rollout in the cross-account post:
- Enable all features in AWS Organizations.
- Finalize OU taxonomy on paper — migrate accounts in waves, not one-by-one ad hoc.
- Attach SCP baselines to Security and Workloads OUs (region allow-list, deny org leave).
- Trial RCP on NonProd OU; watch CloudTrail
AccessDeniedfor partner integrations. - Enable declarative policies (VPC BPA) on Workloads OUs; use Control Tower managed controls if you are on CT.
- Promote RCP to Prod OU, then root if required — only after inventory sign-off.
- Stand up tag policies with FinOps tagging/chargeback alignment.
CCoE and compliance interfaces
Governance without a human interface becomes shadow IT. Pair this model with a CCoE operating model: platform owns OU taxonomy and RFC intake; security owns RCP/data perimeter sign-off; FinOps owns tag policy keys; compliance owns Config conformance packs — see continuous compliance automation.
What to do this week
- Draw your current OU tree — highlight any account without a clear policy home.
- List active SCP detaches — convert each to an RFC with end date or revert.
- Run the policy matrix on your top three controls (public S3, VPC public access, region deny) — label each SCP, RCP, or declarative.
- Pilot RCP on NonProd if you have not already — before root attachment.
What this post doesn’t cover
- Control Tower click-by-click setup — setup guide.
- RAM, Route 53 Profiles, delegated admin mechanics — cross-account patterns.
- FedRAMP / GovCloud-specific accreditation — RCP is available in GovCloud (May 2025), but accreditation boundaries need specialist review; do not infer compliance from this post alone.
- IAM Identity Center permission sets design — identity layer is separate from OU/SCP design.
Related: AWS managed services · Control Tower setup · Cross-account patterns · Tagging & chargeback
If you only do one thing: Inventory SCP detaches and Exceptions OU accounts — every one needs an RFC end date or revert this week.
AWS Cloud Architect & AI Expert
AWS-certified cloud architect and AI expert with deep expertise in cloud migrations, cost optimization, and generative AI on AWS.
