Updated recently
Last updated:
Quick Answer: A workable AWS Organizations OU SCP setup for growing teams in 2026 is a small set of accounts — production, non-production, security/audit, shared services and a sandbox — grouped into OUs under AWS Organizations, with a handful of SCPs acting as hard boundaries: no one can leave the organisation, root cannot act, and non-production cannot touch production or unapproved regions. SCPs only restrict; they never grant, and they do nothing useful while the default FullAWSAccess policy stays attached to every OU.
Why One Account Stops Scaling Around Twelve People
Single-account AWS works right up until it does not, and the failure is rarely dramatic. It shows up as: a developer’s test script hitting production resources because they shared the same credentials; a billing line nobody can attribute because everything is one bill; service quotas — particularly account-level ones for things like VPCs and IAM — being consumed by experimentation; and the hardest problem of all, blast radius. One compromised key, one misapplied policy or one careless DeleteDatabase affects everything, because everything lives together.
Multi-account is how AWS itself recommends solving this, and it has become table stakes for anything past a startup’s first year in India — enterprise and GCC clients ask about account strategy in vendor reviews as a matter of course. The surprising part for most teams is how few accounts you actually need to start. Five to seven, not fifty. Structure beats count.
What Organizations, OUs and SCPs Each Do
| Building Block | What It Does | What It Does Not Do |
|---|---|---|
| Organization | Ties accounts together: consolidated billing, cross-account roles, global policy enforcement | Move resources between accounts automatically |
| OU (organisational unit) | A folder grouping accounts so policies apply by branch | Hold resources — only accounts do |
| SCP | A maximum ceiling on what any principal in an account can do | Grant anything on its own |
| Management account | The account that created the organization; billing anchor | Get special protection — it is the highest-value target |
| Member account | Any other account; isolated credentials, limits and logs | Share IAM users or roles with siblings directly |
The SCP cell is the one to memorise. An SCP attached to an OU is a ceiling: it can remove permissions from the accounts beneath it, but it can never add permissions an identity policy did not already grant. Writing an SCP full of Allow statements and expecting protection is the most common misreading of the whole system — and it fails silently, because nothing errors; the restriction simply never applies.
A Starter Structure That Survives Growth
Root
├── Security OU
│ ├── audit-log-archive (CloudTrail, Config, S3 Object Lock)
│ └── security-tooling (GuardDuty admin, Access Analyzer, SIEM)
├── Infrastructure OU
│ └── shared-services (Transit Gateway, DNS, CI/CD runners)
├── Workloads OU
│ ├── production-* (one account per production system)
│ ├── staging-* (mirrors production structure)
│ └── development (team sandboxes, loose but bounded)
└── Sandbox OU
└── experiments (cheap, noisy, no data, hard limits)
# Creating the tree
aws organizations create-organizational-unit --parent-id ou-root --name "Workloads"
aws organizations create-organizational-unit --parent-id ou-workloads --name "production"
aws organizations create-account --email [email protected] --account-name "prod-payments"
Three design choices in that tree are worth defending in your design review. Separate security tooling into its own account so that an attacker who compromises a workload cannot turn off GuardDuty or delete the audit trail — the logs must live where the workload does not. One account per production system rather than one big production account, which isolates failure and makes cost attribution trivial. A real sandbox OU where experimentation is allowed, because the alternative is engineers doing experiments in production.
How to Write an SCP That Protects Something
Guardrails worth having on day one, because they cost nothing and prevent the irreversible:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "PreventLeavingTheOrganization",
"Effect": "Deny",
"Action": [
"organizations:LeaveOrganization",
"account:Close"
],
"Resource": "*"
},
{
"Sid": "NoRootUsageAnywhere",
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"StringLike": { "aws:PrincipalArn": "arn:aws:iam::*:root" }
}
},
{
"Sid": "BlockUnapprovedRegions",
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"Null": { "aws:RequestedRegion": [
"ap-south-1", "ap-southeast-1", "eu-west-1"
] }
}
}
]
}
Those three cover the classics: nobody removes an account from the organization during an incident, the root user cannot be used even if its credentials are stolen, and workloads cannot spin up in an unapproved region — which both contains costs and satisfies data-residency rules common among Indian financial and healthcare firms. Add a fourth later that denies disabling CloudTrail, GuardDuty or Config across the non-production OUs as well.
Remember the ordering rule from AWS VPC Explained days of networking work: nothing here is a substitute for network isolation. Accounts are the real boundary — VPCs and SCPs reinforce it.
The Guardrail That Guarded Nothing
A SaaS company I worked with in 2025 had done almost everything right on paper: five accounts, a tidy OU tree, and an SCP attached at every level. During a security review we pulled the SCP details and found that FullAWSAccess — the default policy Organizations attaches to every OU when you create it — was still attached alongside each of their custom policies. Because SCPs only intersect, a blanket Allow at the same level cancelled out every restriction they believed they had written.
In practice their “region lockout” allowed any region, their “no leaving the org” rule had no effect, and an incident-response drill discovered that a developer account could still create IAM users — exactly what the SCP was supposed to prevent. Nobody had noticed because the console showed the custom policy attached, in green, with a tick.
The fix took an afternoon: remove FullAWSAccess, attach FullAWSAccess only where deliberately needed, then re-test each guardrail with an action that should fail. An untested guardrail is a document, not a control. The team now tests every SCP with iam simulate-principal-policy as part of the change, the same habit advocated in our cloud security salary guide, where IAM and SCP depth is the top-paying skill.
Which Accounts Do You Actually Need, and When?
| Account | Add It When | Cost of Delay |
|---|---|---|
| Production | Day one | Catastrophic — you have no isolation at all |
| Non-production (dev/staging) | As soon as testing shares credentials | Experiments landing in production |
| Security / audit log archive | Before your first compliance conversation | Logs deletable by a compromised workload |
| Shared services (network, CI/CD) | Second VPC or second team | Networking sprawl and duplicated cost |
| Sandbox | Engineers start asking for prod access to try things | They will try it in prod anyway |
| Per-system production accounts | Around 4–6 production workloads | Blast radius and cost attribution blur |
Rolling This Out Without Breaking Production
- Create the organization from the account you intend to keep as management — you cannot move the management account afterwards. Use consolidated billing benefits immediately.
- Build the OU tree and move accounts one branch at a time. Moving an account between OUs is instant; discovering that an SCP applies to a branch you had forgotten takes longer.
- Apply guardrails first, deny-heavy. Deny-leave, deny-root, region limits. Nothing that can block a running workload until you have tested it in the sandbox OU.
- Test every SCP explicitly. Assume a role, attempt the action you expect to fail. If it succeeds, the SCP is not doing what you think.
- Set up cross-account access via roles, never shared users, and centralise identity through IAM Identity Center so engineers hold one set of credentials and switch roles.
- Automate account creation. Control Tower’s account factory, or Terraform’s Organizations modules, so a new account arrives with baselines instead of a checklist.
Step 6 is where teams get the most long-term value: an account created by hand misses the guardrail baseline every single time, and by the time someone notices, workloads are already in it. Provisioning through code rather than console is the discipline covered in Terraform vs AWS CDK vs CloudFormation.
Training Resources
Multi-account design, SCP strategy and guardrail testing are core modules of SkilBrill AWS Cloud Architecture Training. For the security side — where SCPs interact with IAM boundaries — continue with AWS Cloud Security Training.
FAQ
What is an OU in AWS Organizations?
An organisational unit is a folder inside your organization’s tree that groups accounts so policies — particularly SCPs — apply to that branch. OUs hold no resources themselves; only accounts do.
Does an SCP grant permissions?
No. An SCP is only a ceiling — it restricts what identities in the accounts beneath it can do, and grants nothing by itself. If an identity policy does not allow an action, an SCP cannot make it allowed.
Why do my AWS SCPs seem to do nothing?
Almost always because the default FullAWSAccess policy is still attached alongside your custom SCP — since SCPs intersect, a blanket Allow cancels your Deny. Remove or scope FullAWSAccess, then test the guardrail with an action you expect to fail.
How many AWS accounts should a growing team have?
Five to seven to start: production, non-production, security/log archive, shared services and a sandbox, splitting production further per system around four to six workloads. More accounts than that usually arrive with real organisational complexity, not before.
Can I move an account between OUs?
Yes, moving between OUs is quick and reversible via the Organizations API or console, and SCPs re-evaluate immediately. The account must be detached from its current OU first, and you cannot move the management account at all.
