1. What is AWS Organizations?

AWS Organizations is a service that lets you consolidate multiple AWS accounts into a single organization. It provides centralized billing, account management, and policy-based governance.

2. Key Concepts

  1. Management Account (formerly Master): The account that creates the organization. Pays all bills. Has full control. Cannot be restricted by SCPs. There is exactly one per organization.
  2. Member Accounts: All other accounts in the organization. Can be created from the management account or invited from existing accounts. CAN be restricted by SCPs.
  3. Organizational Unit (OU): A logical container for accounts. OUs can be nested (OU inside OU). You apply SCPs to OUs to govern all accounts within them.
  4. Root: The top-level container in the organization hierarchy. Contains all OUs and accounts. Not the same as the root user.

3. Organization Hierarchy Example

Root
├── Management Account (pays all bills)
├── OU: Production
│   ├── Account: Prod-App-1
│   └── Account: Prod-App-2
├── OU: Development
│   ├── Account: Dev-Team-A
│   └── Account: Dev-Team-B
├── OU: Security
│   └── Account: Security-Audit
└── OU: Sandbox
    └── Account: Sandbox-Testing


4. Key Features of Organizations

Consolidated Billing

  1. Single payment method for all accounts in the organization
  2. Aggregated usage across accounts for volume pricing discounts
  3. Reserved Instance sharing across accounts within the organization
  4. One bill, one payment, easier financial management


Account Management

  1. Create new AWS accounts programmatically via API
  2. Invite existing accounts to join the organization
  3. Move accounts between OUs
  4. Remove accounts from the organization

5. Service Control Policies (SCPs)

SCPs are IAM-like policies that you attach to the Root, OUs, or individual accounts in your organization. They define the MAXIMUM permissions for the affected accounts.

Important Warning SCPs do NOT grant any permissions. They only restrict. An SCP sets the guardrails (ceiling) for what identity-based policies in the account can allow. To actually grant access, you still need IAM policies.

SCP Key Rules

  1. SCPs affect all users and roles in member accounts, including the account root user
  2. SCPs do NOT affect the management account — the management account always has full access
  3. SCPs do NOT affect service-linked roles
  4. SCPs must have an explicit Allow for actions to be permitted (implicit deny otherwise)
  5. SCP Deny overrides any IAM Allow in the member account
  6. SCPs are inherited — an SCP on a parent OU applies to all child OUs and accounts


SCP Strategies

SCP Example: Deny Region Access

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyNonApprovedRegions",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "us-east-1",
            "eu-west-1"
          ]
        }
      }
    }
  ]
}


This SCP denies all actions in any Region except us-east-1 and eu-west-1. Applied to an OU, it prevents all member accounts from using other Regions.


SCP Example: Prevent Leaving the Organization

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "organizations:LeaveOrganization",
      "Resource": "*"
    }
  ]
}


6. Organizations + IAM Policy Evaluation

When an account is in an organization with SCPs:

  1. The SCP must allow the action (or not deny it)
  2. AND the IAM identity policy must also allow the action
  3. Effective permissions = SCP ∩ IAM Policy (intersection)
  4. SCP Deny overrides everything in the member account
Exam Tip Key exam patterns: 1) SCP does NOT affect the management account. 2) SCP does NOT grant permissions, only restricts. 3) SCP affects the root user of member accounts. 4) Consolidated billing = volume discounts + RI sharing. 5) Denylist strategy is more common than Allowlist. 6) SCPs are inherited from parent OUs.