1.2 AWS Organizations, SCPs, and Multi-Account Strategy
Key Takeaways
- AWS Organizations consolidates multiple AWS accounts into a hierarchy of Organizational Units (OUs) with centralized billing.
- Service Control Policies (SCPs) set maximum permission guardrails at the OU or account level — they do NOT grant permissions, they restrict them.
- SCPs do not affect the management account — only member accounts are subject to SCPs.
- AWS Control Tower automates the setup of a multi-account environment with guardrails, landing zones, and account vending.
- A multi-account strategy provides strong isolation for workloads, security boundaries, and billing separation.
AWS Organizations, SCPs, and Multi-Account Strategy
Quick Answer: AWS Organizations lets you manage multiple AWS accounts from a single management account. Service Control Policies (SCPs) set maximum permission boundaries — they restrict what member accounts CAN do but never grant permissions. Use a multi-account strategy to isolate workloads, enforce security boundaries, and simplify billing.
AWS Organizations
AWS Organizations is a free service that lets you consolidate multiple AWS accounts into an organization for centralized management and governance.
Key Features
| Feature | Description |
|---|---|
| Consolidated Billing | Single payment method for all accounts; volume discounts shared |
| Organizational Units (OUs) | Group accounts into a hierarchy (e.g., Production OU, Development OU) |
| Service Control Policies | Permission guardrails applied to OUs or accounts |
| Account Creation | Programmatically create new accounts via API |
| Resource Sharing | Share resources across accounts via AWS RAM |
Organization Structure
Root (Management Account)
├── Production OU
│ ├── Prod-App-A Account
│ ├── Prod-App-B Account
│ └── Prod-Shared-Services Account
├── Development OU
│ ├── Dev-App-A Account
│ └── Dev-App-B Account
├── Security OU
│ ├── Log Archive Account
│ └── Security Tooling Account
└── Sandbox OU
└── Developer Sandbox Accounts
Service Control Policies (SCPs)
SCPs define the maximum permissions for member accounts in an organization. They act as guardrails — they can only restrict, never grant.
SCP Key Rules (Critical for Exam)
| Rule | Explanation |
|---|---|
| SCPs restrict permissions | They set the ceiling, not the floor |
| SCPs do NOT grant permissions | Users still need IAM policies to do anything |
| SCPs affect member accounts only | The management account is NEVER affected by SCPs |
| SCPs apply to all users and roles in affected accounts | Including the account root user |
| SCP Deny overrides IAM Allow | An SCP deny cannot be overridden |
SCP Example: Deny All Except Specific Regions
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyNonApprovedRegions",
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": ["us-east-1", "us-west-2", "eu-west-1"]
}
}
}
]
}
On the Exam: A common question pattern: "How do you PREVENT users in member accounts from launching resources in unapproved Regions?" Answer: Apply an SCP that denies actions in non-approved Regions.
AWS Control Tower
AWS Control Tower automates the setup of a secure multi-account environment based on best practices.
| Feature | Description |
|---|---|
| Landing Zone | Pre-configured multi-account environment |
| Guardrails | Preventive (SCPs) and detective (AWS Config rules) controls |
| Account Factory | Automated account provisioning with pre-configured settings |
| Dashboard | Centralized view of compliance across all accounts |
When to use Control Tower vs. Organizations:
- Organizations only — You need basic multi-account management and SCPs
- Control Tower — You want automated setup, guardrails, account factory, and compliance monitoring
Multi-Account Strategy Benefits
| Benefit | Explanation |
|---|---|
| Security isolation | Compromised account cannot affect others |
| Billing separation | Clear cost attribution per team/project |
| Blast radius reduction | Failed deployments or misconfigurations are contained |
| Compliance | Different accounts can have different compliance controls |
| Service limits | Each account has its own service quotas |
An organization wants to prevent any IAM user or role in its development accounts from launching EC2 instances larger than t3.large. What should they use?
Which statement about Service Control Policies (SCPs) is TRUE?