One allow-list SCP on an OU caps what every account below it can do

SCP Allows intersect down the tree. Every node on the path from root to account filters the set of permitted actions, and IAM inside the account can grant only what gets through ^[3][10]. OUs nest up to five levels under the root ^[4]. A deeply nested account can therefore have seven nodes that must each allow an action: the root, five OUs and the account itself ^[5]. Deny is simpler. Attach it at any node and it applies to everything below ^[2].

The guide's example shows the failure. The root and the prod account both carry FullAWSAccess. The Workloads OU between them carries an allow-list, AllowOnlyApprovedSvc, that permits ec2:* and s3:* and leaves out dynamodb:*. DynamoDB is denied in prod because the OU level never allowed it ^[6]. An IAM policy granting *:* in that account does not change the outcome, and nobody inside the account can override the control ^[3][17].

This is why FullAWSAccess sits at every level by default ^[7]. If an OU's FullAWSAccess is replaced with an allow-list, that list becomes the ceiling for every account underneath ^[7]. According to the guide, the most common SCP incident comes straight from this. Someone detaches FullAWSAccess from an OU while testing an allow-list, and every account below loses the services the list left out ^[8]. The guide recommends explicit Deny statements on top of FullAWSAccess, and allow-lists only when there is a specific reason ^[9]. I think deny-lists are the right default for most organizations. A forgotten Deny leaves one action unguarded. A forgotten Allow at an OU denies that action to every account beneath it ^[7].

Denials also stack across policy types. A principal in a member account needs an Allow from its identity-based policy, from the SCPs in its path, and from the RCPs in its path where the service supports them ^[10]. Permission boundaries, session policies and resource-based policies still apply, and an explicit Deny at any layer wins ^[10]. SCPs and RCPs never grant access ^[10]. When the IAM policy looks right, the guide says to check the SCPs on every node in the account's path, including nodes the account is not directly attached to ^[11].

Policy follows the path, so the OU layout decides which accounts share a ceiling. The guide says to design OUs around the controls and lifecycle you want to apply, because teams get reorganized while the need for stricter guardrails in prod than in sandbox stays the same ^[13]. Its baseline has a Security OU holding a Log Archive account for org-wide CloudTrail and Config data. The same OU holds a Security Tooling account that is delegated administrator for GuardDuty and Security Hub ^[15]. An Infrastructure OU takes networking and shared services, and a Workloads OU splits prod from non-prod so their guardrails can differ ^[15]. Control Tower's preventive controls are SCPs and RCPs, so they land on the same tree ^[16].

The management account sits outside that split. The guide says it owns the organization, is the payer account, and should run organization and billing tasks only, with tightly restricted human access ^[12]. The post presents this as separating the governance plane from workloads ^[12]. It does not tie the rule to SCP evaluation. Its case for keeping workloads in member accounts is isolation: separate accounts give blast-radius isolation and a place to attach controls that no one inside the account can override ^[17]. All of this requires the all-features mode, since consolidated-billing mode only merges invoices ^[14].