AWS Organizations, OUs & Service Control Policies

Organizations creates a hierarchy for governing AWS accounts

AWS Organizations groups AWS accounts into a centrally managed hierarchy. One management account owns the organization, the root sits at the top of the hierarchy, organizational units (OUs) group accounts for administration, and OUs can be nested to represent governance boundaries such as production, infrastructure or sandbox environments. An account belongs directly to one location in that hierarchy—either the root or an OU—while policies attached above it can be inherited down the path.

Account boundaries are useful because they separate resources, billing visibility, permissions and operational blast radius more strongly than simply placing every workload in one account. Organizations also supports consolidated billing and trusted integrations with many AWS services. The management account should be used carefully because it is structurally privileged; AWS recommends minimizing workloads and routine administrative activity there and delegating supported service administration to member accounts where appropriate.

SCPs set a permissions ceiling; they do not grant access

Service control policies (SCPs) are authorization guardrails that define the maximum permissions available to IAM users and roles in member accounts. An SCP never grants an API permission by itself. A principal still needs an applicable IAM identity policy or resource policy that grants access, and the requested action must also survive the SCP guardrails that apply through the organization hierarchy. This intersection is why attaching AdministratorAccess inside a member account cannot override an SCP that blocks the action.

SCP evaluation is hierarchical. An explicit Deny in an applicable SCP blocks the action, and allow-list strategies require the permission to remain allowed through each relevant level from the root down to the account. SCPs apply to IAM principals in member accounts, including the member account root user, but they do not restrict users or roles in the Organizations management account. AWS also documents that service-linked roles are not restricted by SCPs. These exceptions are important when reasoning about what an SCP can and cannot enforce.

• SCP Allow does not grant a permission; IAM/resource policies still have to grant it.
• An applicable explicit Deny wins even if an IAM administrator policy allows the action.
• SCPs affect member accounts, including delegated administrator accounts, but not users or roles in the management account.
• Service-linked roles are outside SCP restriction because AWS services use them for integrated service behavior.

Delegated administration distributes operations without giving away organization ownership

Many AWS services integrate with Organizations through trusted access and support a delegated administrator account. This lets a security, operations or platform account manage that service across the organization without forcing routine service administration into the management account. Delegation is service-specific: becoming a delegated administrator does not turn the member account into a second Organizations management account and does not exempt its principals from SCPs.

A mature multi-account design therefore combines several layers. Organizations establishes account structure and centralized policies; SCPs constrain the permission ceiling; delegated administrators run supported central services; CloudTrail can centralize audit activity; Config can aggregate configuration evidence; and CloudFormation StackSets can deploy standard resources. These tools solve different governance problems and are most effective when they are deliberately composed.