How AWS Organizations, accounts, Organizational Units, and Service Control Policies create security and billing boundaries -- and why a flat single-account architecture is the most common source of production blast-radius incidents.
Understands why multi-account exists and can explain the blast radius isolation benefit. Can create an account in an existing Organisation and configure baseline security (CloudTrail, Config, GuardDuty). Knows what SCPs are and that they are a ceiling, not a grant.
Designs the OU hierarchy and SCP set for a new project or team. Builds the account vending automation. Owns the landing zone design. Explains the tradeoffs between single-account (simple) and multi-account (safe) to product engineering teams.
Defines the organisation-wide account strategy -- how accounts map to teams, products, and environments. Sets the SCP policies that apply to all accounts. Owns the break-glass procedures and the management account hardening policy.
How AWS Organizations, accounts, Organizational Units, and Service Control Policies create security and billing boundaries -- and why a flat single-account architecture is the most common source of production blast-radius incidents.
Developer runs `terraform destroy` to clean up the dev environment for the weekend.
WARNINGTerraform plan shows 47 resources to delete. Developer reviews the plan.
WARNINGDeveloper types `yes`. Terraform begins destroying 47 production resources including 3 RDS instances, 2 ECS clusters, and 12 S3 buckets.
CRITICALMonitoring fires simultaneously for all production services. PagerDuty cascade begins.
CRITICALOn-call engineer declares P0 incident. Root cause: AWS CLI profile pointed at the shared production account, not the dev workspace.
The question this raises
If a developer ran `terraform destroy` right now against what they thought was the dev environment, is there anything preventing them from doing it in production?
You attach a Service Control Policy to an Organizational Unit that contains Allow: s3:GetObject, s3:PutObject. A developer in an account inside that OU tries to delete an S3 object. The developer's IAM role has s3:* (full S3 access). What happens?
Lesson outline
The instinct to use a single AWS account for all environments (dev, staging, prod) feels efficient: one place to look, one IAM configuration, one billing view. The cost shows up in incidents. In a single account, every developer with AWS console access can reach production. A misconfigured IAM policy that is too permissive in dev is also too permissive in prod. A terraform destroy in the wrong workspace takes down production. Account-level rate limits (Lambda concurrency, EC2 vCPU quotas) are shared between dev and prod.
What AWS account boundaries actually provide
The minimum viable multi-account structure is 3 accounts
Management account (billing and Organizations only -- no workloads), Production account (all live customer traffic), Non-production account (dev + staging). Even this basic split eliminates the most common blast-radius incidents. Add a Log Archive account to centralise CloudTrail, Config, and GuardDuty findings outside of reach of any workload account.
AWS Organizations provides two things: consolidated billing across all member accounts, and Service Control Policies (SCPs) that set permission guardrails.
| Concept | What it is | Key property |
|---|---|---|
| Management account | The root account that creates the Organisation; contains billing; should have no workloads | Most privileged account in the Organisation -- credentials must be tightly protected |
| Member account | Any account joined to the Organisation; subject to SCPs from above; has full AWS capability within the bounds SCPs define | Isolated blast radius from all other accounts |
| Organisational Unit (OU) | Logical grouping of accounts; SCPs attached to an OU apply to all accounts in it | Inheritance model -- child OUs inherit parent SCP restrictions |
| Service Control Policy (SCP) | IAM policy applied at the OU or account level; creates a permission boundary; cannot grant permissions -- can only restrict | Evaluated before IAM policies -- acts as a ceiling |
| Root OU | The top of the hierarchy; SCPs here apply to every account in the Organisation | Attach only broadly applicable guardrails here |
SCPs do not grant permissions -- they only restrict them
The most common SCP misunderstanding: "I attached a policy that allows S3 access, so why can't my role access S3?" SCPs are a boundary -- a ceiling. They can prevent AdministratorAccess from touching us-gov regions, even if the IAM policy says Allow *. They cannot give a role access to something it doesn't already have through IAM. Think of SCPs as a firewall over IAM, not a grant mechanism.
Creating AWS accounts manually through the console is a one-time operation. Creating them consistently across a growing engineering organisation requires automation -- account vending.
The account vending pattern
01
Request: engineer or team requests a new account via a form or API (account name, environment type, owning team, cost centre).
02
Automation creates the account: AWS Organizations CreateAccount API, or AWS Control Tower account factory. Account is placed in the correct OU automatically.
03
Baseline configuration applied: CloudTrail, Config, GuardDuty, and SecurityHub enabled. Logging forwarded to the central Log Archive account. Default VPC deleted. SCPs inherited from OU.
04
Access granted: the requesting team receives IAM Identity Center (SSO) access to their account only.
05
Drift detection: AWS Config rules continuously audit account configuration and alert on deviations from the baseline.
Request: engineer or team requests a new account via a form or API (account name, environment type, owning team, cost centre).
Automation creates the account: AWS Organizations CreateAccount API, or AWS Control Tower account factory. Account is placed in the correct OU automatically.
Baseline configuration applied: CloudTrail, Config, GuardDuty, and SecurityHub enabled. Logging forwarded to the central Log Archive account. Default VPC deleted. SCPs inherited from OU.
Access granted: the requesting team receives IAM Identity Center (SSO) access to their account only.
Drift detection: AWS Config rules continuously audit account configuration and alert on deviations from the baseline.
AWS Control Tower automates the landing zone
Control Tower is AWS's managed service for multi-account setup. It creates the account structure, enables GuardDuty, Config, and CloudTrail, and provides an account vending machine (Account Factory). For organisations starting from scratch, Control Tower is the fastest path to a production-ready multi-account setup. For organisations with existing accounts, the migration path is more complex -- use Control Tower Customizations for Control Tower (CfCT) for incremental adoption.
SCPs are the most powerful preventive control in AWS. Applied correctly, they make certain classes of misconfiguration structurally impossible -- not just detectable after the fact.
High-value SCPs for every organisation
Attaching a Deny All SCP to the root OU breaks everything
A Deny All SCP at the root OU applies to every account in your Organisation -- including the management account. This locks you out of all accounts. Always test SCPs on a non-production OU with a canary account before attaching to production OUs. Always keep a break-glass IAM user in the management account that can remove SCPs as a recovery mechanism.
AWS accounts as boundaries
📖 What the exam expects
AWS accounts provide billing separation and can be used to isolate workloads. Multiple accounts are managed via AWS Organizations.
Toggle between what certifications teach and what production actually requires
Senior and principal cloud engineer interviews, cloud architecture design reviews, and compliance/security audit preparations. Often framed as "how would you design the account structure for a new product?" or incident post-mortems asking why blast radius was so large.
Common questions:
Try this question: How many AWS accounts does your organisation currently have? Do you have a landing zone with automated account vending? What SCPs are applied at the root OU level?
Strong answer: Describes at least a 3-account structure unprompted. Mentions Control Tower or CfCT for landing zone automation. Knows the difference between preventive controls (SCPs) and detective controls (Config, GuardDuty). Explains consolidated billing and RI sharing across accounts.
Red flags: Believes a single AWS account with strict IAM policies is sufficient isolation. Thinks SCPs can grant permissions. Does not know what a landing zone is. Cannot explain why the management account should have no workloads.
Ready to see how this works in the cloud?
Switch to Career Paths for structured paths (e.g. Developer, DevOps) and provider-specific lessons.
View role-based pathsSign in to track your progress and mark lessons complete.
Questions? Discuss in the community or start a thread below.
Join DiscordSign in to start or join a thread.