5.1 AWS Organizations Hierarchy, OUs & Account Provisioning

Enterprise Multi-Account Architecture Principles

In modern cloud engineering, managing an enterprise footprint within a single AWS account is considered an anti-pattern. As organizations scale, a single account inevitably encounters hard AWS service quotas (such as API rate limits, VPC limits, and IAM policy size constraints), monolithic blast radiuses where a security compromise affects all environments, and complex, error-prone IAM permission boundaries.

AWS Organizations solves these structural challenges by consolidating multiple AWS accounts into an administratively unified tree structure governed by programmatic policies and centralized billing.

The Need for Multi-Account Isolation

1. Blast Radius Containment: A security compromise, credential leak, or catastrophic operational misconfiguration (such as a destructive deployment script) in a development account remains physically isolated from production workloads and sensitive corporate data.
2. Granular Security and Compliance Boundaries: Highly regulated environments (such as PCI-DSS cardholder data environments or HIPAA health records) can be segregated into dedicated accounts subject to strict audit trails, dedicated encryption keys, and immutable logging.
3. Independent Service Quotas: AWS API rate limits (such as CloudFormation deploy calls, EC2 instance launch limits, and Route 53 queries) apply per account per region. Multi-account partitioning prevents noisy neighbor workloads in development or testing from starving production pipelines.
4. Precise Cost Allocation: While bills are aggregated centrally for volume discounts, individual member accounts provide definitive attribution of infrastructure expenditure to distinct cost centers, business units, or engineering squads without complex tagging heuristics.

---

Recommended AWS Organizations Hierarchy

AWS Well-Architected multi-account guidance recommends organizing accounts into functional Organizational Units (OUs) rather than mirroring corporate reporting structures. The hierarchy branches beneath a single Root container.

                                  [ Organizations Root ]
                                             │
        ┌───────────────────┬────────────────┴────────────────┬───────────────────┐
        ▼                   ▼                                 ▼                   ▼
  [ Security OU ]   [ Infrastructure OU ]              [ Workloads OU ]     [ Sandbox OU ]
   ├─ Log Archive    ├─ Network Account                 ├─ Dev Accounts      └─ Isolated R&D
   └─ Security Tool  └─ Shared Services / Tools         ├─ Test Accounts
                                                        └─ Prod Accounts

Core Organizational Units and Account Roles

---

Automated Account Provisioning and Onboarding

Manually clicking through the AWS Management Console to provision accounts does not scale and introduces human configuration errors. Enterprise DevOps requires continuous, programmatic account provisioning.

The CreateAccount API Mechanics

The AWS Organizations CreateAccount API creates a new member account that automatically joins the organization:

• Asynchronous Execution: Calling aws organizations create-account --email dev-team@corp.internal --account-name "Mobile-App-Dev" initiates an asynchronous workflow and immediately returns a CreateAccountStatus object containing a unique Id (e.g., car-1234567890abcdef0).
• Status Tracking: The status transitions through IN_PROGRESS to either SUCCEEDED or FAILED. The provisioning orchestration must poll DescribeCreateAccountStatus using the request Id, or reactively listen for state changes.
• Default IAM Role: By default, AWS Organizations automatically creates an IAM role named OrganizationAccountAccessRole inside the new member account. This role grants AdministratorAccess and establishes an IAM trust relationship allowing principals in the Management account to assume it via AWS STS.

[!IMPORTANT] DOP-C02 Exam Trap — Created vs. Invited Accounts: When an account is created using CreateAccount, AWS automatically deploys the OrganizationAccountAccessRole. However, when an existing standalone AWS account is brought into the organization via InviteAccountToOrganization, AWS does not create this role! Administrators must manually create an IAM cross-account role with trust back to the Management account, or deploy it using an onboarding script before centralized automation can manage the invited account.

Event-Driven Account Provisioning Pipeline

To enforce security baselines on newly created accounts before releasing them to engineering teams, DevOps teams construct event-driven onboarding pipelines combining Amazon EventBridge, AWS Step Functions, and AWS CloudFormation StackSets:

[ Organizations: CreateAccount API ]
                │
                ▼
  [ Account Provisioned (SUCCEEDED) ]
                │
                ▼ (Emits AWS API Call via CloudTrail)
       [ Amazon EventBridge ]
                │
                ▼ (Triggers)
     [ AWS Step Functions ]
        │
        ├─ 1. MoveAccount: Relocate from Root to target Workload OU
        ├─ 2. TagResource: Apply mandatory CostCenter, Owner, and Env tags
        ├─ 3. CloudFormation StackSets: Deploy baseline VPC, IAM roles, and KMS keys
        ├─ 4. AWS Config & GuardDuty: Verify member enablement
        └─ 5. Notify Team: Send provisioning success notification via Amazon SNS

1. Event Capture: CloudTrail captures the completion of CreateAccount and forwards the CreateAccountResult event to Amazon EventBridge in the Management account.
2. State Machine Execution: An EventBridge rule detects the successful account creation and invokes an AWS Step Functions state machine.
3. OU Relocation: Step Functions executes an AWS Lambda task that invokes organizations:MoveAccount, specifying the AccountId, the SourceParentId (initially the Organization Root), and the DestinationParentId (e.g., the Dev-Workloads-OU). Moving the account causes it to immediately inherit all Service Control Policies (SCPs) attached to the target OU.
4. Baseline StackSet Deployment: CloudFormation StackSets with automatic deployment enabled (AutoDeployment: Enabled: true, RetainStacksOnAccountRemoval: false) automatically detect the new account in the target OU. StackSets immediately provisions baseline infrastructure: local security groups, VPCs, IAM roles for CI/CD runners, and default Amazon EBS volume encryption (ec2:EnableEbsEncryptionByDefault).
5. Identity & Access Integration: The state machine registers the new account with AWS IAM Identity Center (AWS SSO) and assigns preconfigured permission sets to designated Active Directory / Okta groups.

---

Governance Beyond SCPs: Organizations Management Policies

While Service Control Policies (SCPs) restrict authorization (detailed in Section 5.2), AWS Organizations supports specialized declarative management policies to maintain corporate compliance across all member accounts.

1. Tag Policies

Tag Policies define standardized tagging rules across an organization. They enforce key-value pair conventions for metadata such as CostCenter, Environment, and ProjectOwner:

• Schema Enforcement: Specifies the exact case-sensitive key name (e.g., Environment rather than environment or env) and an allowed list of valid values (e.g., ['development', 'staging', 'production']).
• Non-Compliance Auditing: Automatically evaluates resources across member accounts and generates non-compliance reports in the AWS Organizations console.
• Preventive Enforcement: When tag enforcement is enabled for supported resource types, AWS denies any API call that attempts to create a resource or modify tags with non-compliant keys or values.

{
  "tags": {
    "CostCenter": {
      "tag_key": {
        "@@assign": "CostCenter"
      },
      "tag_value": {
        "@@assign": [
          "Finance-101",
          "Engineering-202",
          "Security-303"
        ]
      },
      "enforced_for": {
        "@@assign": [
          "ec2:instance",
          "s3:bucket"
        ]
      }
    }
  }
}

2. Backup Policies

Backup Policies define organization-wide AWS Backup plans deployed automatically to member accounts. Instead of each engineering team writing independent backup scripts, a centralized backup policy configures:

• Resource assignment rules based on resource tags (e.g., resources tagged BackupPlan: Gold).
• Backup frequency (e.g., daily snapshots retained for 35 days).
• Cross-Region and cross-account backup copies (e.g., copying snapshots to a dedicated, locked backup vault in the Log Archive or Security Tooling account for ransomware protection).

3. AI Service Opt-Out Policies

Enterprise compliance frameworks frequently prohibit cloud vendors from utilizing proprietary customer data to train artificial intelligence models. AI Service Opt-Out Policies allow organizations to opt out of having content stored or processed by AWS AI services (such as Amazon Rekognition, Amazon Transcribe, Amazon Comprehend, and Amazon Bedrock) utilized for AWS model training and quality improvement.

---

Consolidated Billing and Cost Governance

AWS Organizations consolidates the payment method for all member accounts into the single Management account:

• Volume Tiering: Usage across all member accounts is aggregated for pricing tiers. For instance, data transferred out of Amazon S3 or EC2 across 50 member accounts is pooled, qualifying the company for higher-volume, lower-per-gigabyte pricing tiers much faster.
• Savings Plans and Reserved Instance (RI) Sharing: By default, unused Reserved Instance hours and Savings Plans commitments purchased in one account apply across all eligible usage within the organization. If a business unit requires strict budget boundaries without cross-subsidization, RI discount sharing can be selectively disabled for specific member accounts.
• Cost Allocation Tags: User-defined cost allocation tags activated in the Management account propagate to billing reports (AWS Cost and Usage Report - CUR) across all member accounts, providing unified spend visibility in AWS Cost Explorer.