AWS Organizations and Accounts

As your AWS usage grows, a single account quickly becomes limiting. AWS Organizations lets you centrally manage multiple AWS accounts, apply policies, consolidate billing, and enforce governance at scale. Most professional AWS environments use multiple accounts as a core architectural principle.

---

Why Multiple Accounts?

Using multiple AWS accounts is an AWS best practice, not just a convenience. Each account provides:

Benefit	Explanation
Security isolation	A blast radius boundary — a compromise in one account does not affect others
Billing separation	Track costs per team, project, or environment
Service limit isolation	Each account has its own service quotas, preventing one workload from starving another
Compliance boundaries	Different compliance requirements can be applied per account
Administrative delegation	Different teams can have admin access to their own accounts without affecting others

Common Account Structure

AWS Organization
├── Management Account (root) — billing, governance, no workloads
├── OU: Security
│   ├── Audit Account — CloudTrail, Config, GuardDuty central
│   └── Log Archive Account — centralised logging
├── OU: Production
│   ├── Prod-App-A Account
│   └── Prod-App-B Account
├── OU: Development
│   ├── Dev-App-A Account
│   └── Dev-App-B Account
├── OU: Staging
│   └── Staging Account
└── OU: Sandbox
    └── Sandbox Account (for experimentation)

---

AWS Organizations Concepts

Management Account (Root Account)

• The account that creates the organisation
• Has full control over all member accounts
• Responsible for consolidated billing
• Best practice: Do not run workloads in the management account — use it only for governance

Member Accounts

• Any account invited to or created within the organisation
• Subject to policies applied by the management account
• Can be moved between Organisational Units

Organisational Units (OUs)

OUs are containers for accounts within an organisation. They provide a hierarchical structure for applying policies:

• OUs can be nested (up to 5 levels deep)
• Policies applied to an OU affect all accounts within it
• Common OU names: Production, Development, Staging, Security, Sandbox

---

Service Control Policies (SCPs)

SCPs are the most powerful governance tool in AWS Organizations. They define the maximum permissions available to accounts or OUs — even if an IAM policy grants broader access.

How SCPs Work

Effective permissions = IAM policy ∩ SCP

If the SCP does not allow an action, no IAM policy can grant it.
If the SCP allows an action, the IAM policy must also grant it.

SCP Examples

Deny creating resources outside approved Regions:

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

Deny disabling CloudTrail:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyCloudTrailDisable",
      "Effect": "Deny",
      "Action": [
        "cloudtrail:StopLogging",
        "cloudtrail:DeleteTrail"
      ],
      "Resource": "*"
    }
  ]
}

SCP vs IAM Policies

Feature	SCP	IAM Policy
Scope	Entire account or OU	Individual users, groups, or roles
Purpose	Set permission boundaries (guardrails)	Grant specific permissions
Default	Allow all (unless deny is added)	Deny all (unless allow is added)
Affects root user?	Yes	No
Can grant permissions?	No — only allow or deny	Yes

---

Creating and Managing Accounts

Creating a New Account