Multi-account security: Organizations, SCPs and Control Tower
7 min read · about 1 h 5 min with practice3 quick checks≈3% of the testCore: Core: tested on most papers
Reading is free. Sign in to tick off lessons, keep your place and track your mastery.
Once a company has more than a handful of AWS accounts, security works at the organization level: guardrails apply to whole groups of accounts, account administrators cannot switch off logging, and resources are shared instead of copied. SAA-C03 tests whether you can put a preventive control in the right place once, and whether you know what SCPs can and cannot do.
By the end you’ll be able to
Design an OU structure and apply SCPs that restrict Regions, services or actions without granting permissions
Predict the effective permissions when SCPs, identity policies and resource policies combine (including the management-account exemption)
Use AWS Control Tower for a governed landing zone with preventive and detective controls and Account Factory
Share resources across accounts with AWS RAM (subnets, Transit Gateways, Resolver rules) and use aws:PrincipalOrgID conditions
Centralise CloudTrail, Config and security findings in dedicated log-archive and audit accounts
What the exam asks
Organize accounts with AWS Organizations and OUs, and use consolidated billing.
Write or choose an SCP (restrict Regions, deny leaving the organization, protect logging) and predict its effect.
Know the exceptions: the management account, service-linked roles and principals from outside the organization.
Use Control Tower to build a best-practice landing zone with the least effort.
Share VPC subnets, Transit Gateways and Resolver rules with AWS RAM, and grant access to the whole organization with aws:PrincipalOrgID.
Centralize CloudTrail, Config and security findings.
Core ideas
Organizations building blocks
The management account creates the organization and pays the consolidated bill. It should run no workloads.
Member accounts sit in organizational units (OUs) under the root.
A typical OU layout:
A Security OU with the Log Archive and Audit (security tooling) accounts.
An Infrastructure OU for networking and shared services.
A Workloads OU with Prod and Non-prod child OUs.
Sandbox and Suspended OUs.
SCPs, RCPs, tag policies and backup policies all require the all features mode. The consolidated billing mode gives one bill and shares volume pricing, Reserved Instance discounts and Savings Plans across accounts, and nothing else.
Service control policies
SCPs set the maximum permissions for IAM users and roles in member accounts, including each member account’s root user.
SCPs never grant permissions. A principal still needs an identity-based or resource-based allow.
SCPs do not affect the management account or service-linked roles. They also do not restrict principals from outside the organization who use your resources.
Inheritance: an SCP must allow an action at every level, from the root through each OU to the account itself. A deny at any level applies to everything below it.
Deny-list strategy: keep FullAWSAccess attached and add deny statements. This is the common, low-maintenance approach.
Allow-list strategy: remove FullAWSAccess and allow only named services.
vii.Check your understanding
3 questions on multi-account security: Organizations, SCPs and Control Tower. Every option is explained once you answer.
Sign in to try the quick check
Answers are checked on our side, every option is explained, and your result feeds your mastery for this topic. It’s free.
NotAction keeps global services working, and aws:PrincipalArn exempts the role.
Resource control policies
RCPs are the resource-side counterpart of SCPs. They cap what anyone can do to resources in member accounts, whoever the caller is. Supported services include Amazon S3, AWS STS, AWS KMS, Amazon SQS and AWS Secrets Manager. That makes RCPs the tool for a data perimeter, such as “no principal outside our organization may access our buckets, even if a bucket policy allows it”.
SCP
RCP
Limits
Principals in member accounts
Resources in member accounts
Stops an external account that a bucket policy grants access to
No
Yes
Stops your own users from calling a service
Yes
Only when they access the covered resources
Grants anything
No
No
Effective permissions
A request is allowed only when all of the following are true:
An identity-based or resource-based policy allows it.
The SCPs allow it.
The RCPs allow it.
The permissions boundary allows it, if one is set.
No policy explicitly denies it.
For access from another account, the policies in both accounts must allow it.
AWS Control Tower
Control Tower builds and governs a landing zone on top of AWS Organizations. The landing zone includes:
A Security OU with Log Archive and Audit accounts.
An organization CloudTrail trail and AWS Config.
Optionally, IAM Identity Center for sign-in.
Controls (formerly guardrails) come in three types:
Preventive controls are policies, such as SCPs, that block actions.
Detective controls are Config rules.
Proactive controls are CloudFormation hooks.
Controls are also labelled mandatory, strongly recommended or elective. Account Factory provisions new accounts that are compliant from day one, and the dashboard reports drift and non-compliance.
When the stem says “best practices”, “landing zone” or “LEAST operational overhead to set up many accounts”, choose Control Tower over building the same pieces yourself with StackSets.
Sharing and organization-wide grants
AWS RAM shares resources without copying them. Examples:
VPC subnets, known as VPC sharing. The owner manages the VPC, route tables and network ACLs, and participants launch their own resources into the subnets.
Transit Gateways.
Route 53 Resolver rules.
Prefix lists, License Manager configurations and more.
S3 buckets are not shared through RAM.
Resource-based policies can allow the whole organization with the aws:PrincipalOrgID condition key, or specific OUs with aws:PrincipalOrgPaths. New accounts then get access automatically.
Centralized logging and security
Organization trail: you create it in the management account or a delegated administrator account. It logs every account and Region, and member accounts cannot change or delete it. Deliver its logs to an S3 bucket in the Log Archive account.
AWS Config aggregator: gives a compliance view across accounts and Regions.
Delegated administrator: lets you run GuardDuty, Security Hub, Config, Firewall Manager, IAM Access Analyzer and other services from the Audit account. Services such as GuardDuty can also be enabled automatically in new accounts.
Worked examples
Exam technique
“Prevent”, “restrict” or “ensure no account can” across many accounts → SCP (principal side) or RCP (resource side).
“Grant”, “allow” or “give access” → never an SCP. Look for an identity-based or resource-based policy.
“All current and future accounts” → a control at the root or OU level. That means an SCP, an RCP, an organization trail, a delegated administrator with automatic enablement, or an aws:PrincipalOrgID condition, not a list of accounts.
“Set up quickly, following best practices” → Control Tower.
“Share subnets or a transit gateway” → AWS RAM.
Common mistakes
Quick recap
Use Organizations with all features for one bill, shared discounts and policy-based guardrails.
SCPs and RCPs only limit permissions. Identity-based and resource-based policies grant them.
SCPs do not affect the management account, service-linked roles or external principals.
An action must be allowed at every level, and a deny at any level wins.
Control Tower provides a landing zone, Log Archive and Audit accounts, controls and Account Factory.
RAM shares subnets, Transit Gateways and Resolver rules. aws:PrincipalOrgID grants access to the whole organization.
An organization trail and delegated administrators centralize logging and security findings.