A Practical Guide to Organizations, SCP, and Multi-Account Governance for the SCS-C03 Exam
_Category: Governance_
As cloud environments mature, the cracks in a single-AWS-account model start to show. When development, operations, and security teams share one account, permission boundaries blur, and a mistake in one environment can ripple across your entire platform. A multi-account strategy is not optional — for any enterprise-scale cloud operation, it is the baseline assumption. This guide walks through the complete picture of multi-account governance using AWS Organizations, SCP, Control Tower, and Resource Access Manager (RAM), anchored in real-world practitioner perspective.
---
Why Multi-Account: The AWS Account as an Isolation Boundary
An AWS account is not just a billing unit. It is a powerful isolation boundary where IAM policies, security groups, VPCs, and service quotas are all enforced independently. Resources in different accounts cannot reach each other without explicit cross-account policies.
There are four driving reasons for a multi-account strategy. Security isolation ensures a breach in one account cannot spread to others. Compliance scoping lets you isolate PCI-DSS workloads into a dedicated account. Cost visibility makes it straightforward to attribute spending to specific teams or projects. Service quota separation means one team exhausting a quota does not affect any other team.
Multi-account setups do introduce management complexity — that is exactly the problem AWS Organizations and Control Tower are designed to solve.
---
AWS Organizations and OU Design Patterns
AWS Organizations is the service that brings multiple AWS accounts together under a single organization and manages them centrally. Inside the organization, accounts are arranged in a tree structure of OUs (Organizational Units). Think of the OU hierarchy like a corporate org chart: a headquarters (root) at the top, business divisions (OUs) below it, and individual team accounts at the leaves.
The OU design pattern recommended for most enterprise environments looks like this:
| OU | Accounts Included | Purpose | |---|---|---| | Security OU | Log Archive, Security Tooling | Centralized log collection, security tools (Security Hub Delegated Administrator, etc.) | | Infrastructure OU | Shared Services, Network | Shared VPC, Transit Gateway, DNS | | Sandbox OU | Developer experiment accounts | Relaxed-policy experimental environment, away from production guardrails | | Workloads OU | Dev, Staging, Prod | Actual service workloads | | Suspended OU | Inactive accounts | Quarantine zone before account closure |
The Log Archive account is a dedicated account that collects CloudTrail and Config logs from every other account. It is isolated so that logs cannot be deleted or tampered with from other accounts. The Security Tooling account acts as the Delegated Administrator for Security Hub and GuardDuty, centralizing security findings across the entire organization.
---
SCPs Precisely Defined: A Ceiling on Permissions, Not a Grant
SCPs (Service Control Policies) are the most frequently misunderstood concept in AWS Organizations. SCPs do not grant permissions. SCPs define the maximum boundary of permissions that can be allowed within an account or OU. Think of them as a company-wide Code of Conduct: individuals (IAM policies) can only act within what the Code permits — the Code itself gives them no special authority.
Understanding the distinction between SCPs and IAM policies clearly is one of the most important skills for the exam.
| Dimension | SCP | IAM Policy | |---|---|---| | Applied to | Entire account or OU (including root) | Individual users, roles, or groups | | Can grant permissions | No — sets boundary only | Yes — grants permissions directly | | Can be overridden | Account admins cannot remove it | Admins can modify or delete it | | Scope | All IAM entities within member accounts | Only the attached entity | | Applies to Management account | No | Yes |
SCP evaluation flows top-down: root → parent OU → child OU → account. Every layer's SCP and the IAM policy must all allow an action before it is permitted. A single explicit Deny anywhere in the chain blocks the request.
Three SCP patterns appear most often in practice: region restriction (using the aws:RequestedRegion condition key), root account protection, and preventing security service deactivation. When restricting regions, you must use NotAction to exclude global services — IAM, CloudFront, Route 53, STS — from the restriction.
---
Control Tower and Landing Zone: Governance on Autopilot
Control Tower is like a standardized franchise playbook for opening new branches. For teams building a multi-account environment from scratch, it automatically configures a best-practice baseline structure called a Landing Zone, eliminating the repetitive manual work of creating OUs, attaching SCPs, and provisioning accounts.
Here are the key components Control Tower sets up in your Landing Zone automatically:
| Component | Description | |---|---| | Root OU | Organization top level; home of the Management account | | Security OU | Auto-creates Log Archive account + Audit account | | Sandbox OU | Isolated environment for experimentation | | Guardrails (Controls) | Preventive and detective governance rules applied automatically | | Account Factory | Provisions new accounts with a standardized configuration | | Dashboard | Unified compliance status view across all accounts |
Guardrails come in two varieties. Preventive Guardrails are implemented as SCPs — they block the creation of non-compliant resources before it happens. Detective Guardrails are implemented as AWS Config rules — they detect violations after the fact and send alerts.
Account Factory runs on Service Catalog under the hood. When a new account request arrives, it applies a predefined template — VPC settings, IAM roles, tags, log routing — and delivers a standardized account. Account Factory for Terraform (AFT) extends this so you can manage the full account lifecycle as infrastructure as code using Terraform.
It is also worth knowing the other Organizations policy types. Tag Policy enforces tagging standards at the organization level. AI Services Opt-out Policy applies a blanket opt-out across all accounts so that AI services like Amazon Rekognition and Comprehend cannot use your data for model training. Backup Policy centrally enforces AWS Backup plans organization-wide.
---
Org-Wide Security Services: Integrating Security Hub, GuardDuty, Config, and Macie
In a multi-account environment, enabling security services account-by-account creates a management burden that scales badly. AWS provides Organizations integration for each major security service, so a single configuration automatically enables the service across all accounts and lets you manage everything centrally from one place. The account that takes on that central management role is called the Delegated Administrator.
The sequence in which you enable org-wide security services matters. Start with AWS Config — Security Hub only works correctly when Config is already active, because Security Hub's security standards (CIS, AWS Foundational Security) rely directly on Config rule evaluation results. After Config is running, set GuardDuty to auto-enable across the organization, then enable Security Hub. GuardDuty findings will automatically flow into Security Hub without needing an EventBridge rule. Macie follows the same pattern — enable and manage it from the Delegated Administrator account.
The Delegated Administrator account should be your Security Tooling account, not the Management account. Delegating to a dedicated account minimizes permission exposure on the Management account, which is best kept out of day-to-day security operations.
Here is a summary of Organizations integration across key security services:
| Service | Delegated Administrator | Auto-Enable | Centralized Aggregation | |---|---|---|---| | Security Hub | Supported | Supported | All Regions aggregated to a single Aggregation Region | | GuardDuty | Supported | Supported | Member findings visible from administrator account | | AWS Config | Supported | Requires additional setup | Multi-account aggregation via Config Aggregator | | Amazon Macie | Supported | Supported | Member findings visible from administrator account | | IAM Access Analyzer | Supported | Supported | Organization-scope analyzer creation |
---
Resource Access Manager and Cross-Account Resource Sharing
Resource Access Manager (RAM) lets you share AWS resources with other accounts or with your entire Organizations hierarchy. It is the right tool when it is cheaper and simpler to share one resource than to have each account create its own duplicate.
The resources most commonly shared through RAM include VPC subnets, Transit Gateway, Route 53 Resolver rules, and License Manager licenses. VPC subnet sharing is by far the most prevalent pattern. A central networking account creates a shared VPC and shares specific subnets with workload accounts. Each workload account deploys EC2 instances into those subnets while maintaining its own independent IAM and security boundaries — shared infrastructure, separated control planes.
Within an organization, RAM shares take effect automatically — recipients do not need to accept an invitation. Shares to accounts outside the organization do require explicit acceptance.
Another pillar of cross-account access design is IAM Identity Center (formerly SSO). Integrated with Organizations, it provides single sign-on across multiple accounts and lets you manage Permission Sets centrally. The best practice is to map Identity Center users and groups to Permission Sets rather than creating individual IAM users in every account.
---
Tricky Governance Scenarios on the Exam
Here are the scenario types that appear repeatedl