14.1 AWS Organizations Structure, Hierarchy & Resource Control

14.1 AWS Organizations Structure, Hierarchy & Resource Control

Modern enterprise security architectures in AWS mandate a multi-account strategy to establish strong isolation boundaries. Relying on a single AWS account with sprawling IAM policies inevitably leads to permission sprawl, cross-application blast radius exposure, and compliance audit friction. AWS Organizations provides the foundational backbone for multi-account governance, programmatic account provisioning, consolidated billing, and policy-driven guardrails across an enterprise cloud estate.

---

Multi-Account Security Architecture & Organizational Structure

The AWS Well-Architected Framework recommends partitioning workloads into dedicated accounts structured by environment lifecycle (such as production, staging, and development), business capability, compliance boundary (such as PCI DSS or HIPAA scopes), and centralized shared infrastructure (such as dedicated network, security, and logging accounts).

Loading diagram...

Hierarchical Components

An AWS Organizations hierarchy consists of distinct structural entities:

1. Management Account: The foundational account that creates the organization. It holds consolidated billing authority, manages organization-level configurations, and administers policies. It was previously termed the master account.
2. Member Accounts: Individual AWS accounts that belong to the organization. A member account can be provisioned programmatically via the Organizations API or invited from an existing standalone account.
3. Root: The top-level administrative parent container for all accounts and Organizational Units within the organization.
4. Organizational Unit (OU): A logical container for accounts within a root. OUs can be nested up to 5 levels deep below the root container, allowing security architects to model corporate hierarchies and compliance tiers.

Organization Feature Sets

AWS Organizations supports two operational modes:

• Consolidated Billing: Provides shared billing, volume tiering, and consolidated payments across accounts, but does not support governance policies like Service Control Policies.
• All Features: Enables comprehensive governance, including Service Control Policies (SCPs), Resource Control Policies (RCPs), Tag Policies, Backup Policies, AI Service Opt-Out Policies, and integration with AWS security services. Transitioning from Consolidated Billing to All Features requires an invitation approval handshake from all invited member accounts.

---

Service Control Policies (SCPs): Mechanics & Filtering Logic

Service Control Policies (SCPs) are organization-level policies that define the maximum available permissions for affected member accounts. They establish guardrails that limit what actions identities (IAM users, IAM roles, and member account root users) within those accounts can perform.

Core Security Principle: SCPs never grant permissions. They act strictly as authorization filters or boundaries. An API action in a member account is permitted if and only if:

1. An explicit identity-based or resource-based IAM policy in the member account grants the permission, AND
2. Every SCP in the direct hierarchy path from the Root through all parent OUs down to the target account allows the action, AND
3. No SCP in that hierarchy path explicitly denies the action.

Effective Permissions = (IAM Allow) ∩ (Root SCP) ∩ (Parent OU SCPs) ∩ (Account SCP) - (Explicit Denies)

Allow-List vs. Deny-List Strategies

When managing SCPs, organizations choose between two operational paradigms:

Critical Scope Boundaries & Exemptions

Understanding where SCPs do and do not apply is a primary focus of the AWS Certified Security – Specialty examination:

• Management Account Immunity: SCPs do not apply to the Management account. Neither IAM principals nor the root user of the Management account are constrained by SCPs.
• Service-Linked Roles: SCPs do not restrict actions performed by AWS service-linked roles. Service-linked roles are predefined by AWS services to perform tasks on your behalf and bypass SCP filtering.
• Resource-Based Policies: While SCPs do not evaluate resource-based policies directly, they filter the calling principal if that principal resides within a member account subject to the SCP.

---

Critical SCP Guardrail Patterns

Security engineers implement defensive SCPs at the Root or OU level to enforce non-negotiable enterprise perimeters.

1. Preventing Member Accounts from Leaving the Organization

Adversaries or rogue administrators seeking to bypass corporate oversight often attempt to remove a compromised account from the organization. The following statement permanently blocks this action across all member accounts:

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

2. Protecting Security Infrastructure & Audit Logging

To prevent unauthorized disabling of foundational audit pipelines, an SCP must deny modifications to CloudTrail, AWS Config, and Amazon GuardDuty:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ProtectSecurityTooling",
      "Effect": "Deny",
      "Action": [
        "cloudtrail:StopLogging",
        "cloudtrail:DeleteTrail",
        "cloudtrail:UpdateTrail",
        "config:DeleteConfigRule",
        "config:StopConfigurationRecorder",
        "config:DeleteDeliveryChannel",
        "guardduty:DeleteDetector",
        "guardduty:DisassociateFromMasterAccount",
        "guardduty:UpdateDetector"
      ],
      "Resource": "*"
    }
  ]
}

3. Restricting Authorized Deployment Regions

Enterprises often mandate that workloads operate strictly within authorized geographic regions to satisfy latency, data sovereignty, and security posture monitoring requirements. When crafting a region-restriction SCP, security engineers must use NotAction to exempt global services that operate without regional endpoints:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUnapprovedRegions",
      "Effect": "Deny",
      "NotAction": [
        "a4b:*",
        "budgets:*",
        "ce:*",
        "chime:*",
        "cloudfront:*",
        "cur:*",
        "globalaccelerator:*",
        "health:*",
        "iam:*",
        "importexport:*",
        "organizations:*",
        "route53:*",
        "route53domains:*",
        "shield:*",
        "sts:*",
        "support:*",
        "wafv2:*",
        "wellarchitected:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "us-east-1",
            "us-west-2"
          ]
        }
      }
    }
  ]
}

Exam Tip: Neglecting to exempt global services like iam:*, cloudfront:*, route53:*, and sts:* in a region restriction SCP will immediately break identity token issuance, global DNS resolution, and IAM administrative operations across member accounts.

---

Resource Control Policies (RCPs): Centralized Perimeter Control

While SCPs govern principals (identities) inside your organization, they cannot restrict external principals accessing resources inside your accounts. If a developer accidentally configures an Amazon S3 bucket policy to allow access from "Principal": "*", an SCP will not stop external threat actors from reading that bucket because the external caller is not subject to your organization's SCPs.

Resource Control Policies (RCPs) resolve this gap by establishing centralized, maximum permissions boundaries directly on resources owned by accounts within the organization. RCPs apply to a growing list of services, including Amazon S3, AWS STS, AWS KMS, Amazon SQS, AWS Secrets Manager, Amazon DynamoDB, Amazon ECR, Amazon Cognito user pools, CloudWatch Logs, and Amazon OpenSearch Serverless. They don't affect resources in the management account, service-linked roles, or AWS managed KMS keys, and custom RCPs contain only Deny statements.

Loading diagram...

Enforcing a Data Perimeter via RCP

An RCP applied at the organization root can enforce that data stored in Amazon S3 or encrypted under AWS KMS keys cannot be accessed by any principal outside the organization, establishing an ironclad data perimeter:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EnforceDataPerimeterOnS3",
      "Effect": "Deny",
      "Principal": "*",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:PrincipalOrgID": "o-exampleorg123"
        },
        "Bool": {
          "aws:PrincipalIsAWSService": "false"
        }
      }
    }
  ]
}

---

AI Service Opt-Out Policies & Data Privacy Compliance

Enterprises operating under stringent data protection standards (such as GDPR, HIPAA, or strict financial privacy mandates) require assurance that proprietary customer data is never retained or utilized by cloud providers for foundation model training or service improvements.

AI Service Opt-Out Policies provide organization-wide governance over whether supported AWS AI services may store and use customer content for service improvement. Supported services include Amazon Rekognition, Amazon Comprehend, Amazon Lex, Amazon Polly, Amazon Textract, Amazon Transcribe, Amazon Translate, and Amazon Q Developer. Amazon Bedrock is not on the list because it doesn't use prompts or completions to train AWS or third-party models in the first place. Opting out also deletes content previously stored for service improvement.

{
  "services": {
    "@@operators_allowed_for_child_policies": ["@@none"],
    "default": {
      "@@operators_allowed_for_child_policies": ["@@none"],
      "opt_out_policy": {
        "@@operators_allowed_for_child_policies": ["@@none"],
        "@@assign": "optOut"
      }
    }
  }
}

The default key covers every current and future supported AI service. @@assign alone only sets a value that child policies can still override with their own @@assign (for example, opting one account in to Amazon Lex). Adding "@@operators_allowed_for_child_policies": ["@@none"] at each level, as shown, locks the opt-out so OUs and accounts can't change it, and the effective policy of each account gives auditors verifiable evidence.

Declarative Policies: Enforcing Service Configurations

Declarative policies (Organizations policy type, introduced December 2024) set the desired configuration of a service across accounts, and the service itself enforces it. Unlike SCPs, which allow or deny API calls, a declarative policy fixes the configuration, so it still holds when new APIs appear and applies even to actions taken by service-linked roles. For Amazon EC2 they can enforce:

• VPC Block Public Access (block internet gateway traffic in VPCs, with exclusions)
• Serial console access off
• Image (AMI) block public access and Allowed AMIs (only AMIs from approved providers can be discovered and launched)
• Instance metadata defaults (for example, require IMDSv2 on new instances)
• EBS snapshot block public access

You can add a custom error message that users see when a policy blocks them, and generate an account status report to check current settings before enforcing a policy.

---

Backup Policies & Tag Policies

Beyond authorization guardrails, AWS Organizations supports operational governance policies that automate compliance baselines:

Backup Policies

Backup Policies centralize the management of AWS Backup plans across all member accounts. Rather than requiring individual account administrators to define backup schedules and retention rules, security engineers define organization-wide backup policies that:

• Automatically bind backup plans to resources matching standardized tags (e.g., BackupPlan: Gold).
• Enforce cross-Region and cross-account backup copy operations to dedicated air-gapped backup accounts.
• Direct those copies to vaults protected by AWS Backup Vault Lock (configured on the vault itself), so ransomware or insiders can't delete recovery points before retention expires.

Tag Policies

Tag Policies enforce standardized metadata tagging across accounts. Tagging standards are essential for attribute-based access control (ABAC), cost allocation, and automated security scanning. Tag policies specify:

• Mandatory tag keys and allowed case-sensitive values (e.g., enforcing Environment with values ["Production", "Staging", "Development"] and flagging case variants such as environment).
• Enforced resource types (such as EC2 instances, S3 buckets, and RDS databases).
• Non-compliance reporting visible in the AWS Organizations console and evaluable by AWS Config rules.

---

Specialty Exam Traps & Architectural Pitfalls

1. Assuming SCPs Constrain the Management Account: The Management account is completely exempt from SCPs. A compromised root credential or administrator role in the Management account can bypass every SCP in the organization. Day-to-day workloads and security tooling must never run in the Management account.
2. Blocking Global Services with Region SCPs: When enforcing geographic region restrictions, always use NotAction to exclude global services. A policy using Action: "*" with a condition StringNotEquals: {"aws:RequestedRegion": ["us-east-1"]} will immediately block IAM, CloudFront, Route 53, and STS, taking down critical administrative and authentication pipelines.
3. Confusing SCPs and RCPs: SCPs restrict principals inside your organization. RCPs restrict resources owned by your organization. An SCP cannot prevent an external attacker from reading a misconfigured public S3 bucket; an RCP can.
4. Prerequisites for Leaving an Organization: A member account cannot leave an organization via organizations:LeaveOrganization unless it has fulfilled the prerequisites to operate as a standalone account: it must have a valid payment method on file, verified contact information, and an accepted AWS customer agreement.