AWS Organizations & SCP: Multi-Account Management and Security Guardrails

Key Takeaway

AWS Organizations centrally manages multiple AWS accounts, and SCPs (Service Control Policies) set account-level permission boundaries (guardrails). SCPs do not grant permissions—they only restrict the maximum allowed scope within what IAM policies permit.

What is AWS Organizations?

A service that consolidates multiple AWS accounts into a single organization.

┌─────────────────────────────────────────────────┐
│                  Organization                    │
│                                                  │
│  ┌────────────────┐                              │
│  │ Management     │  ← Org management, billing   │
│  │ Account        │     Not affected by SCPs     │
│  └────────────────┘                              │
│         │                                        │
│  ┌──────┴──────────────────────────────┐         │
│  │              Root                    │         │
│  ├──────────────┬───────────────────────┤         │
│  │              │                       │         │
│  │  ┌───────┐  │  ┌─────────────┐      │         │
│  │  │ Prod  │  │  │   Dev       │      │         │
│  │  │ OU    │  │  │   OU        │      │         │
│  │  ├───────┤  │  ├─────────────┤      │         │
│  │  │Acct A │  │  │  Acct C     │      │         │
│  │  │Acct B │  │  │  Acct D     │      │         │
│  │  └───────┘  │  └─────────────┘      │         │
│  └─────────────┴────────────────────────┘         │
└─────────────────────────────────────────────────┘

Key Features

Feature	Description
Consolidated Billing	Combine costs from all accounts into one
Volume Discounts	Higher discounts from aggregated usage
SCP	Account-level security guardrails
OU (Organizational Unit)	Group accounts into categories
Account Creation	Automated account creation via API

OU (Organizational Unit) Design

Typical OU Structure

Root
├── Security OU
│   ├── Log Archive Account
│   └── Security Tooling Account
├── Infrastructure OU
│   ├── Shared Services Account
│   └── Networking Account
├── Workloads OU
│   ├── Production OU
│   │   ├── App A Prod
│   │   └── App B Prod
│   └── Development OU
│       ├── App A Dev
│       └── App B Dev
└── Sandbox OU
    └── Personal experiment accounts

OU Design Principles

1. Separate by purpose: Security, Infrastructure, Workloads, Sandbox
2. Separate by environment: Production vs Development
3. Policy application convenience: Apply policies uniformly per OU
4. Least privilege: Allow only minimum required permissions per OU

Understanding SCPs (Service Control Policies)

The Role of SCPs

SCPs do not grant permissions. They limit the maximum scope that IAM policies within accounts can allow.

Effective Permissions = IAM Policy ∩ SCP

Example:
IAM Policy: Allows S3, EC2, RDS
SCP: Allows only S3, EC2
→ Effective Permissions: S3, EC2 (RDS blocked by SCP)

SCP Application Rules

Rule	Description
Management Account	Not affected by SCPs
Member Accounts	SCPs applied
Root User	Restricted by SCPs
Inheritance	Root → OU → Account (cascading)
Max attachments	5 SCPs per entity
Max size	5,120 characters per SCP

SCP Strategies: Deny List vs Allow List

Deny List - Recommended

Keep the default FullAWSAccess policy and block only specific risky actions.

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

Advantages:

• New AWS services are automatically allowed
• Simple and safe to implement
• Low risk of service disruption

Allow List

Remove the default FullAWSAccess and allow only specific services.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:*",
        "s3:*",
        "rds:*"
      ],
      "Resource": "*"
    }
  ]
}

Caution: New services require manual addition, and services may be accidentally blocked.

Common SCP Examples

1. Region Restriction

Allow AWS services only in specific regions:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAllOutsideAllowedRegions",
      "Effect": "Deny",
      "NotAction": [
        "iam:*",
        "organizations:*",
        "sts:*",
        "support:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "ap-northeast-2",
            "us-east-1"
          ]
        }
      }
    }
  ]
}

2. Block Root User Actions

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyRootUser",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringLike": {
          "aws:PrincipalArn": "arn:aws:iam::*:root"
        }
      }
    }
  ]
}

3. Prevent CloudTrail Disabling

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

4. Prevent S3 Public Access Block Removal

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyS3PublicAccessBlockRemoval",
      "Effect": "Deny",
      "Action": [
        "s3:PutBucketPublicAccessBlock",
        "s3:PutAccountPublicAccessBlock"
      ],
      "Resource": "*"
    }
  ]
}

SCP vs IAM Policy

Aspect	SCP	IAM Policy
Applies to	Entire account (OU/Account)	Users, Groups, Roles
Grant permissions	Not possible	Possible
Restrict permissions	Possible	Possible
Restrict root user	Possible	Not possible
Management account	Not applicable	Applicable
JSON syntax	Same as IAM policy	-

AWS Control Tower

A multi-account environment automation service that automatically sets up Organizations + SCPs.

Control Tower Guardrails

Type	Implementation	Example
Preventive	SCP	Region restriction, CloudTrail protection
Detective	AWS Config	Detect unencrypted resources

SAA-C03 Exam Focus Points

1. ✅ SCP characteristics: "Cannot grant permissions, only limits maximum allowed scope"
2. ✅ Management account: "Not affected by SCPs"
3. ✅ Root user: "SCPs can restrict root user in member accounts"
4. ✅ Region restriction: "Use NotAction to exclude global services"
5. ✅ Consolidated billing: "Volume discounts, RI/SP sharing"

Frequently Asked Questions

Q: Do SCPs affect existing resources?

SCPs only apply to new API calls. Existing resources remain, but operations to modify or create new resources may be blocked.

Q: Can I apply SCPs to the management account?

No. The management account is not affected by SCPs. Best practice is to use the management account only for organization management and run workloads in member accounts.

Q: What happens when SCPs and IAM policies conflict?

Effective permissions are the intersection of SCPs and IAM policies. If SCP blocks, it's blocked even if IAM allows.

Q: Does joining Organizations cost anything?

AWS Organizations itself is free. You can receive volume discount benefits through consolidated billing.

Q: Can I remove an account from the organization?

Yes. Member accounts can be removed. However, to convert to a standalone account, payment methods must be configured. You can prevent unauthorized departures by blocking LeaveOrganization with an SCP.

Related Posts

• IAM Basics: Users, Groups, Roles, Policies
• IAM Policy Writing and Evaluation Logic
• IAM Role vs User

References

• AWS Organizations SCP Documentation
• SCP Examples
• AWS Organizations Best Practices