Organizations

Centrally manage billing, access control, and compliance across multiple AWS accounts

AWS Organizations lets you centrally manage multiple AWS accounts under a single organizational hierarchy, applying policies for billing consolidation, access control, and compliance across all accounts at scale. It is the prerequisite for almost every AWS enterprise governance service, including Control Tower, Service Control Policies, and organization-wide Config rules.

Organizational Units, Account Structure, and Hierarchy Design

An Organization has a single management account (formerly called master account) at the root. Below the root, you create Organizational Units (OUs) to group accounts by environment, business unit, or function. Accounts can be moved between OUs and policies are inherited hierarchically.

Component	Description	Key Points
Management Account	The account that creates and owns the organization	Cannot be restricted by SCPs; pay all consolidated bills; has full org access
Member Account	Any account in the org that is not the management account	Can be created from within the org or invited to join
Root	Top-level container for all OUs and accounts	Policies applied here affect every account in the org
Organizational Unit (OU)	Container within the root or another OU for grouping accounts	Up to 5 levels deep; policies are inherited by nested OUs and accounts

A common account structure separates concerns by OU: Security OU (Log Archive account, Security Tooling account), Infrastructure OU (Networking account, Shared Services account), Workloads OU (Dev accounts, Staging accounts, Prod accounts), and Sandbox OU (individual developer accounts with guardrails).

💡

Put the management account in a Management OU (not Root) and apply an SCP that denies all workload operations from the management account. The management account should be used only for billing, organization management, and IAM Identity Center - never run workloads in it.

Service Control Policies - The Most Powerful Governance Tool

Service Control Policies (SCPs) are JSON policies that define the maximum permissions available to member accounts. They act as guardrails: even if an IAM user or role in a member account has full AdministratorAccess, an SCP can prevent them from performing certain actions.

IAM Policy Allows	SCP Allows	Effective Permission
s3:DeleteBucket	Yes	Allowed
s3:DeleteBucket	No (explicit deny)	Denied
s3:DeleteBucket	Not mentioned	Denied (SCPs are allow-list by default)
ec2:TerminateInstances	Yes	Allowed
Not mentioned in IAM	Yes	Denied (IAM still applies)

SCPs use allow-list or deny-list mode. In allow-list mode (default after Organizations is set up), the FullAWSAccess policy is attached to root by default; you remove permissions by adding explicit Deny SCPs. In deny-list mode, you remove FullAWSAccess and only allow specific actions.

⚠️

SCPs do NOT apply to the management account, service-linked roles, or the root user of a member account. This is a critical security consideration: the management account is always unrestricted, which is why you should never run production workloads there.

json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyLeavingOrganization",
      "Effect": "Deny",
      "Action": "organizations:LeaveOrganization",
      "Resource": "*"
    },
    {
      "Sid": "DenyOutsideApprovedRegions",
      "Effect": "Deny",
      "NotAction": [
        "iam:*",
        "sts:*",
        "support:*",
        "organizations:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": ["us-east-1", "us-west-2", "eu-west-1"]
        }
      }
    }
  ]
}

Consolidated Billing, Savings Plans Sharing, and Delegated Admin

All member accounts roll their costs up to the management account for consolidated billing. The key financial benefit is that usage-based discounts (Reserved Instances, Savings Plans, volume pricing tiers) are shared across the entire organization.

Benefit	How It Works
Consolidated bill	Single invoice for all accounts; management account pays all charges
RI sharing	EC2 Reserved Instances purchased in any account benefit all accounts in the org (unless sharing disabled)
Savings Plans sharing	Compute Savings Plans apply across all accounts in the org automatically
Volume pricing tiers	S3, Data Transfer, and other tiered services aggregate usage across all accounts
Free tier aggregation	Each account still gets its own free tier (unlike RI/SP sharing)

Delegated Administrator allows you to designate a member account (not the management account) to manage specific services across the organization. For example, you can designate a Security account as delegated admin for GuardDuty, Security Hub, and Config Aggregator - keeping security tooling separate from the management account.

💡

Delegated Admin is a key pattern for the Control Tower Security OU design. The Security Tooling account becomes the delegated admin for security services, enabling the security team to operate their tools without needing access to the management account.

Tag Policies, AI Services Opt-Out, and Backup Policies

Beyond SCPs, Organizations supports three additional policy types that enforce operational governance:

Policy Type	What It Enforces	Use Case
Tag Policies	Standardized tag key/value formats across all resources	Enforce cost allocation tags, environment tags, owner tags at org level
AI Services Opt-Out Policies	Prevent AWS AI services from using your content to improve models	Privacy compliance, data sovereignty for sensitive workloads
Backup Policies	Enforce backup plans and retention rules across accounts via AWS Backup	Compliance-driven backup requirements (RPO/RTO mandates)

Tag policies don't deny resource creation if tags are missing (unlike what many people expect). They define what values are valid for a given tag key. To actually enforce tag presence, combine tag policies with Config rules (require-tags managed rule) or SCPs with tag condition keys.

bash

# Create and attach a tag policy
aws organizations create-policy \
  --name "env-tag-policy" \
  --description "Enforce valid values for Environment tag" \
  --type TAG_POLICY \
  --content file://tag-policy.json

aws organizations attach-policy \
  --policy-id p-xxxxxxxxxx \
  --target-id ou-xxxx-xxxxxxxx  # Attach to OU

🎯

Interview Focus Points

1What is the difference between SCPs and IAM policies - can an SCP grant permissions?
2Explain how SCP allow-list vs deny-list mode works and give an example of each.
3Why should you never run production workloads in the management account of an AWS Organization?
4How does Reserved Instance and Savings Plan sharing work across an organization?
5What is a delegated administrator and why is it useful for security tooling?
6How would you use SCPs to enforce that all workloads only deploy to approved AWS regions?
7What is the difference between an SCP and a Permission Boundary - when would you use each?
8How do tag policies work and what are their limitations for enforcing tagging compliance?