Skip to main content

AI & assistant-friendly summary

This section provides structured content for AI assistants and search engines. You can cite or summarize it when referencing this page.

Summary

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...

Key Facts

  • •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

Entity Definitions

EC2
EC2 is an AWS service discussed in this article.
S3
S3 is an AWS service discussed in this article.
DynamoDB
DynamoDB is an AWS service discussed in this article.
CloudWatch
CloudWatch is an AWS service discussed in this article.
IAM
IAM is an AWS service discussed in this article.
VPC
VPC is an AWS service discussed in this article.
Route 53
Route 53 is an AWS service discussed in this article.
OpenSearch
OpenSearch is an AWS service discussed in this article.

Enterprise AWS Governance (2026): OU Taxonomy, Policy Layering, and Exception RFCs That Scale

Cloud ArchitecturePalaniappan P5 min read

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
Enterprise AWS Governance (2026): OU Taxonomy, Policy Layering, and Exception RFCs That Scale
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:

  1. Security OU — log archive, audit, security tooling; highest policy intensity; no application workloads.
  2. Infrastructure OU — network hub (Transit Gateway, egress), shared CI/CD, DNS; RAM shares originate here.
  3. Sandbox OU — individual accounts with spend caps and short lifetimes.
  4. Workloads OU — split NonProd and Prod; optionally Tier-1 vs Tier-2 prod for different RCP/SCP strictness.
  5. Exceptions OU — time-boxed only; every account has an exit_by date.

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:

JobToolCommon mistake
Cap what your identities can doSCPUsing SCP to simulate VPC config (brittle per API)
Cap what anyone can do to your resourcesRCPSCP-only data perimeter (external principal + bucket policy)
Enforce config end state (e.g. VPC BPA)Declarative policySCP deny on one disable API
Require cost/security tagsTag policySCP (cannot enforce all tag values on create)
Detect drift after deployAWS ConfigExpecting 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 CreateVpc in 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:

  1. Enable all features in AWS Organizations.
  2. Finalize OU taxonomy on paper — migrate accounts in waves, not one-by-one ad hoc.
  3. Attach SCP baselines to Security and Workloads OUs (region allow-list, deny org leave).
  4. Trial RCP on NonProd OU; watch CloudTrail AccessDenied for partner integrations.
  5. Enable declarative policies (VPC BPA) on Workloads OUs; use Control Tower managed controls if you are on CT.
  6. Promote RCP to Prod OU, then root if required — only after inventory sign-off.
  7. 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

  1. Draw your current OU tree — highlight any account without a clear policy home.
  2. List active SCP detaches — convert each to an RFC with end date or revert.
  3. Run the policy matrix on your top three controls (public S3, VPC public access, region deny) — label each SCP, RCP, or declarative.
  4. 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.

Frequently asked questions

How many OUs should an enterprise AWS organization have?
Enough OUs to attach different policy intensities — not one OU per team. A common enterprise pattern is five to seven top-level OUs: Security (log archive, audit), Infrastructure (network hub, shared services), Sandbox, Workloads split into NonProd and Prod (optionally Tier-1 vs Tier-2 prod), and a small Exceptions OU for time-boxed migrations. If two OUs carry identical SCP, RCP, and declarative attachments, merge them. If prod HIPAA and prod general need different RCP/data rules, split. Account count alone does not drive OU count; policy divergence does.
We already have Control Tower — do we still need a separate governance design?
Yes. Control Tower is an implementation path for a landing zone — account factory, baseline controls, guardrails. It does not decide your OU taxonomy, how exceptions work, or how SCP/RCP/declarative/tag policies layer. AWS added declarative-policy managed controls in December 2024; RCP service coverage expanded through February 2026. Your governance model should name which control type owns which risk, independent of whether you clicked enable in Control Tower or attached policies via Organizations APIs.
When should we use a declarative policy instead of another SCP?
Use declarative policies when you need a configuration end state enforced at the service control plane — today EC2, VPC, and EBS (for example VPC Block Public Access, blocking public AMIs or EBS snapshots). SCPs that deny one API break when AWS ships a new API reaching the same end state. Declarative policies maintain the declared state across new APIs, accounts, and resources. Keep SCPs for identity-side caps (deny leaving the org, deny disabling CloudTrail, region allow-lists). Use RCPs for data perimeters on supported resource types.
When should we NOT attach an RCP at the organization root?
Do not attach a broad RCP at the root until you have inventoried cross-account and partner access patterns — silent Deny on S3, DynamoDB, or logs breaks pipelines. Roll out RCPs on a NonProd OU first, monitor CloudTrail AccessDenied for several days, then promote. Remember RCPs do not protect resources in the management account; workloads should not live there. Also confirm the resource type is on the current RCP support list (expanded through January–February 2026 for Cognito, CloudWatch Logs, DynamoDB, and others).
How do governance exceptions work without turning into permanent holes?
Route exception accounts to a dedicated Exceptions OU with a documented exit date (max 90 days unless security extends). Attach a narrow exception SCP or relaxed policy only to that OU/account — never detach baseline controls org-wide. Require an RFC with compensating controls, approvals, and auto-revert calendar. When the date hits, move the account to the correct OU or decommission. Permanent policy changes go through normal change management, not the exception RFC.
How does this relate to the cross-account patterns post?
The cross-account post is mechanism-by-job after the landing zone (RAM, delegated admin, Route 53 Profiles, RCP syntax, declarative rollout). This post is org design: OU taxonomy, which policy type owns which risk, and how humans request temporary relief. Read both — start here for structure, then cross-account for day-2 operations.
Palaniappan P
Palaniappan P

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.

AWS ArchitectureCloud MigrationGenAI on AWSCost OptimizationDevOps

Recommended Reading

Explore All Articles »
5 min

Cross-Account Patterns Beyond the Landing Zone (2026): RAM, Delegated Admin, Route 53 Profiles, RCPs, and Declarative Policies

Your landing zone set up the org, OUs, and baseline SCPs — then most teams stall, duplicating resources per account and wiring brittle cross-account role chains. Since re:Invent 2024 the toolkit changed: RCPs bound what can be done TO a resource (even by external principals), declarative policies enforce EC2/VPC/EBS config state that survives new APIs, and one Route 53 Profile can push DNS to up to 5,000 VPCs. Here is the mechanism-by-job decision matrix and a rollout order that avoids lockouts.