Instiq
Chapter 1 · Design Solutions for Organizational Complexity·v2.1.0·Updated 7/16/2026·~11 min

What's changed: Service coverage: added a catalog section (s4) for governance/security/end-user services

1.1Multi-Account Strategy and Governance

Key points

Understand the foundation for large organizations: AWS Organizations, Organizational Units (OUs), Service Control Policies (SCPs), consolidated billing, and Control Tower. Operate many accounts securely and with governance.

At the professional level, governing many accounts is central. AWS Organizations groups accounts into a hierarchy with centralized guardrails and billing.

1.1.1AWS Organizations structure

Diagram of an AWS Organizations structure: a management account at the top, OUs nested under the root (e.g., Security OU, Workloads OU, Sandbox OU), with member accounts in each OU; SCPs (permission ceilings) applied to OUs/accounts; consolidated billing aggregating cost; and Control Tower automating multi-account setup and guardrails.
AWS Organizations and governance
  • AWS Organizations: centrally manage accounts in a root → OU → account hierarchy.
  • SCP: defines the permission ceiling (guardrail) for OUs/accounts; it restricts rather than grants.
  • Consolidated billing: aggregates billing across the org, sharing volume discounts and RIs/Savings Plans.
  • Control Tower: automates setup and guardrails for a multi-account landing zone.
Exam point

Common on SAP-C02: an SCP is a permission ceiling, not a grant (an action needs both IAM allow AND SCP allow), org-wide billing aggregation = consolidated billing, landing-zone automation = Control Tower. Note SCPs do not affect the management account’s root user.

Note

SCPs do not apply to the management account itself. A common pattern is to isolate critical controls in dedicated OUs (e.g., Security/Infrastructure).

Professional multi-account design builds on AWS Organizations, grouping purpose-specific accounts into OUs (e.g., Security OU = log archive/audit, Infrastructure OU = shared networking, Workloads OU = prod/dev, Sandbox OU). Account separation localizes blast radius and gives billing/permission boundaries and dedicated service quotas. An SCP is a permission ceiling (guardrail); effective permissions are IAM allow ∩ SCP allow (explicit DENY always wins), combining inherited FullAWSAccess with explicit Deny for region/service limits. Control Tower auto-builds a landing zone (multiple OUs, centralized logging, SSO) and applies controls (formerly guardrails) as preventive (SCP)/detective (Config rules)/proactive (CloudFormation Hooks), provisioning standardized accounts via Account Factory (or AFT). Cross-account governance uses a Config aggregator, an organization CloudTrail trail, and delegated administrators (centralize GuardDuty/Security Hub in the Security account). Consolidated billing shares RIs/Savings Plans and volume discounts org-wide while cost allocation tags and AWS Budgets give per-account visibility.

MechanismRoleEffect
SCPPermission ceiling for OUs/accountsBoth with IAM; DENY wins
IAM policyGrant permissions to principalsActually grants
Control TowerLanding zone/controls automationPreventive/detective/proactive
Consolidated billingAggregate billing, share discountsOrg-wide optimization
Note

Scenario: across all accounts, forbid non-approved regions and root-user access-key creation. → Attach Deny-based SCPs to the root/relevant OUs (Deny all actions in non-approved regions; Deny iam:CreateAccessKey for root). Provision new accounts with the same guardrails via Control Tower Account Factory, and detect drift with Config and Security Hub.

Note

FAQ: Q. Can an SCP “grant” permissions? → A. No—an SCP only sets a ceiling; IAM grants. An action needs both to allow, and DENY always wins. Q. Centralize org-wide threat detection? → A. Aggregate GuardDuty/Security Hub under a delegated administrator (Security account), enabled org-wide.

Warning

Trap: “assigning an SCP grants users permissions” is wrong—an SCP is a ceiling; IAM grants (need both; DENY wins). Also “SCPs apply to the management account too” is wrong—they don’t, so put critical controls on member accounts under dedicated OUs.

1.1.2Section summary

  • Organizations = hierarchical governance root → OU → account
  • SCP = permission ceiling / billing = consolidated / automation = Control Tower

Sign in to track progress — Log in.

Quick check

(just a quick review)

Q1. You must impose a guardrail so accounts under a given OU can never use regions other than allowed ones. What do you use?

Q2. Which statement about SCPs is correct?

Q3. Which managed capability quickly provisions many new accounts with standardized guardrails?

Check your understandingPractice questions for Chapter 1: Design Solutions for Organizational Complexity