AWS Organizations: OUs, SCPs, and Hierarchy

AWS Organizations is a global service that enables you to consolidate multiple AWS accounts into a single organizational unit. It provides centralized management of billing, access control, compliance, and resource sharing across accounts. The service is free of charge and is a prerequisite for many advanced AWS features such as AWS Single Sign-On (SSO), AWS Control Tower, and consolidated billing.

At its core, AWS Organizations creates a hierarchy with one management account (formerly called the master account) and up to 10,000 member accounts (by default, but can be increased via support request). The management account has full administrative control over all member accounts, including the ability to create new accounts, invite existing accounts, apply policies, and view consolidated billing data.

When you create an organization, AWS automatically creates a root container. All accounts (management and member) reside under this root. You can then create Organizational Units (OUs) — logical containers that group accounts with similar needs (e.g., Production, Development, Sandbox). OUs can be nested up to 5 levels deep. The hierarchy is a tree structure: root → OU → sub-OU → account.

Policies, such as Service Control Policies (SCPs) and backup policies, are attached to nodes in the hierarchy (root, OUs, or directly to accounts). When a policy is attached to a node, it applies to all accounts within that node and all child nodes. This is called policy inheritance. For example, an SCP attached to the root applies to every account in the organization. An SCP attached to the Production OU applies only to accounts in that OU and its sub-OUs.

To create an organization via AWS CLI:

aws organizations create-organization --feature-set ALL

Output:

{
    "Organization": {
        "Id": "o-xxxxxxx",
        "Arn": "arn:aws:organizations::123456789012:organization/o-xxxxxxx",
        "FeatureSet": "ALL",
        "MasterAccountId": "123456789012",
        "MasterAccountEmail": "admin@example.com"
    }
}

To create an OU:

aws organizations create-organizational-unit --parent-id r-xxxx --name "Production"

To create an SCP:

aws organizations create-policy --content file://policy.json --name "DenyS3Delete" --type SERVICE_CONTROL_POLICY --description "Deny S3 delete actions"

To attach an SCP to an OU:

aws organizations attach-policy --policy-id p-xxxx --target-id ou-xxxx

To verify effective permissions, use the IAM policy simulator or check CloudTrail logs for denied actions.

A large bank needs to enforce strict compliance across 500 AWS accounts. They use AWS Organizations with OUs for each business unit (e.g., Retail Banking, Investment Banking, Risk Management). SCPs are applied to deny access to non-US regions (to comply with data residency laws), prevent deletion of CloudTrail logs, and block the use of unapproved instance types. The bank also uses SCPs to require encryption on all S3 buckets (by denying s3:PutObject without the x-amz-server-side-encryption header). In production, they test SCPs on a 'Sandbox' OU first. A common misconfiguration is forgetting to exclude the management account from SCPs, but that is not needed as SCPs don't apply to it. However, they must ensure IAM policies in member accounts do not grant more permissions than allowed by SCPs. Performance is not an issue as SCPs are evaluated instantly. When a developer accidentally attaches a deny-all SCP to the root, all accounts (except management) lose access; recovery requires the management account to detach the SCP.

A SaaS company hosts customer environments in separate AWS accounts. They use Organizations with OUs per customer tier (e.g., Gold, Silver, Bronze). SCPs enforce network isolation: they deny creating security group rules that allow inbound traffic from 0.0.0.0/0, and they require all EC2 instances to be launched in a specific VPC. They also use SCPs to limit instance types to cost-effective families. The company creates new accounts programmatically via the AWS Organizations API and moves them to the appropriate OU. A common issue is that SCPs can break AWS services like AWS Lambda if they deny iam:PassRole for the Lambda service-linked role. They mitigate by using aws:SourceArn condition keys in SCPs to allow only specific actions. They also use AWS Control Tower to automate the setup, which pre-configures mandatory SCPs.

A media company uses consolidated billing to aggregate costs across 200 accounts. They create OUs by department (e.g., Engineering, Marketing, HR) and use cost allocation tags to track spending. SCPs are used to enforce tagging: they deny creating resources without required tags (e.g., CostCenter, Project). This is done by denying ec2:RunInstances unless the request includes the required tags (using condition keys). In production, they monitor CloudTrail for 'AccessDenied' errors to identify misconfigured SCPs. A common mistake is applying an SCP that denies iam:Create* to the entire organization, which breaks the ability to create new member accounts (since that requires iam:CreateAccount). They learned to exclude the management account from such SCPs (but SCPs don't apply to management anyway) and to use separate OUs for accounts that need to create IAM resources.