Free lesson · AWS Fundamentals

AWS account structure and the multi-account default

Easy7 min read

The Account Is The Boundary

On AWS, the account is the strongest isolation boundary that exists. Everything else - VPCs, IAM policies, tags, resource-level permissions - is a boundary you configure and can misconfigure. The account boundary is structural.

An AWS account isolates four things simultaneously:

Boundary	What it means
Security	IAM principals are account-scoped. Cross-account access requires an explicit, deliberate grant on both sides.
Blast radius	A compromised credential, a runaway script, or a bad deployment is contained to the account it ran in.
Quotas	Service quotas are per-account per-Region. One team's load test cannot exhaust another team's Lambda concurrency.
Billing	Charges are attributable to the account with no tagging discipline required.

That last point is underrated. Cost attribution by tag depends on every engineer tagging every resource correctly forever. Cost attribution by account is automatic and cannot be forgotten.

Important: The industry default is now many accounts, not one. A single account holding development, staging, and production is not a simplification - it is a decision to have no isolation boundary between them, with the practical consequence that a mistake in development can consume production's quota, and a compromised developer credential is a production credential.

AWS Organizations

Organizations is the service that makes many accounts manageable rather than chaotic.

Management account (formerly "master"). Creates the organisation, owns consolidated billing, applies policies. It has powers no policy can restrict - critically, Service Control Policies do not apply to the management account.

Organizational Units (OUs). A hierarchy for grouping accounts so policies apply to groups rather than individuals.

Member accounts. Where workloads actually run.

Service Control Policies (SCPs). Guardrails that set the maximum available permissions for accounts in an OU. An SCP never grants anything - it only bounds what IAM in the member account is allowed to grant. Effective permission is the intersection of the SCP and the IAM policy.

Consolidated billing. One bill, and - importantly - Reserved Instances and Savings Plans purchased anywhere in the organisation apply automatically to matching usage in any account.

Warning: Do not run workloads in the management account. It is the account with unrestricted power, it cannot be constrained by SCPs, and compromising it compromises the entire organisation. It should contain Organizations configuration, billing, and essentially nothing else. This is the most common structural mistake in AWS environments that grew organically.

A Reference Account Structure

graph TD
    ROOT[Organization Root] --> MGMT[Management Account<br/>billing + org config only]
    ROOT --> SEC[Security OU]
    ROOT --> INF[Infrastructure OU]
    ROOT --> WKL[Workloads OU]
    ROOT --> SBX[Sandbox OU]
    ROOT --> SUS[Suspended OU]
    SEC --> LOG[Log Archive Account]
    SEC --> AUD[Security Tooling Account]
    INF --> NET[Network Account]
    INF --> SHR[Shared Services Account]
    WKL --> PRD[Prod OU]
    WKL --> NPD[Non-Prod OU]
    PRD --> P1[App A Prod]
    PRD --> P2[App B Prod]
    NPD --> N1[App A Dev/Test]
    NPD --> N2[App B Dev/Test]

This diagram shows a reference AWS Organizations structure as a tree. The organization root contains a management account holding only billing and organization configuration, plus five organizational units. The Security OU contains a Log Archive account and a Security Tooling account. The Infrastructure OU contains a Network account and a Shared Services account. The Workloads OU splits into a Production OU and a Non-Production OU, each containing per-application accounts. There is also a Sandbox OU for experimentation and a Suspended OU for decommissioned accounts.

What each part is for:

Log Archive - the write-once destination for CloudTrail, Config, and VPC Flow Logs from every account. Almost nobody has write access; investigators have read access. This is what preserves evidence when another account is compromised.
Security Tooling - GuardDuty, Security Hub, and Detective, configured as delegated administrator so findings from all accounts aggregate here.
Network - centrally owned Transit Gateway, shared VPC subnets, Direct Connect, and DNS. Application teams consume networking rather than build it.
Shared Services - CI/CD, artifact repositories, golden AMI pipelines, directory services.
Prod / Non-Prod split at the OU level - lets you apply materially different SCPs. Non-prod can be denied expensive instance families and restricted to two Regions; prod can be denied the ability to disable CloudTrail or delete log buckets.
Sandbox - real isolation for experimentation, with a hard budget and aggressive SCPs.
Suspended - decommissioned accounts, denied everything, retained for audit.

Tip: The granularity question - one account per application, per team, or per environment - has no universal answer, but the useful heuristic is: split where you need a different blast radius, a different quota pool, or a different set of people with access. Two applications operated by the same team with the same data sensitivity rarely need separate accounts. Production and development always do.

Control Tower And Account Vending

Building the structure above by hand is possible and painful. AWS Control Tower automates it: it sets up the organisation, the core OUs, the log archive and audit accounts, a baseline of guardrails, and an Account Factory for provisioning new accounts with the baseline already applied.

The pattern it implements is account vending - a new account arrives with logging enabled, CloudTrail sent to the log archive, guardrails applied, network attached, and identity federated, before anyone can put a workload in it. The alternative, where each new account is configured by whoever requested it, guarantees drift.

Control Tower is opinionated. Organisations with existing complex structures sometimes find its assumptions constraining and build equivalent automation themselves with Organizations, CloudFormation StackSets, and IaC. Either is defensible; doing neither is not.

Identity Across Accounts

Many accounts creates an obvious problem: nobody wants twenty sets of credentials.

The answer is IAM Identity Center federating from a single identity source - your corporate directory or an external IdP. Users authenticate once and assume roles into whichever accounts they are entitled to, with permission sets defining what they can do there. No IAM users, no long-lived access keys, no per-account credential sprawl.

For machine access, the equivalent is role assumption: a pipeline in the Shared Services account assumes a deployment role in the target account, scoped to exactly what it needs. For CI running outside AWS, OIDC federation replaces stored access keys entirely.

Important: Multi-account without federated identity is worse than single-account. You get the isolation benefit and pay for it with credential sprawl that undermines the isolation. Identity Center - or an equivalent federation setup - is not an optional later phase. It is part of the multi-account design.

Common Failure Modes

Warning: Workloads in the management account. Covered above. The most consequential structural error.

Root user left unprotected. Every account has a root user that IAM policies and SCPs cannot fully restrict. It needs MFA, no access keys, a monitored recovery email, and an alarm on any use of it. In a hundred-account organisation this is a hundred root users.

SCPs that grant. SCPs only limit. A common misunderstanding is expecting an SCP to give an account a permission its IAM policies do not.

Testing SCPs in production first. An overly broad Deny at the root OU can lock every account out of a service instantly, including the automation that would fix it. Test in a sandbox OU.

Accounts created outside the vending process. They lack logging, guardrails, and network attachment, and nobody discovers this until an audit or an incident.

Splitting so far that nothing can talk to anything. Two hundred accounts with no shared networking, no central logging, and no federated identity is a different failure, not an improvement.

Why This Matters In An Interview

Interview: What interviewers are listening for:

You reach for multi-account for isolation reasons, and you can name the four boundaries it provides rather than saying "best practice."

You know SCPs bound rather than grant, and that effective permission is the intersection with IAM.

You do not put workloads in the management account, and you can say why.

Common follow-ups:

"How would you stop a developer from launching resources in an unapproved Region?" → SCP with a Deny on all actions where the requested Region is not in an allowed list, applied at the OU level, with exceptions for global services whose endpoints live in a specific Region.

"How do you prevent someone from disabling CloudTrail to cover their tracks?" → SCP denying cloudtrail:StopLogging and cloudtrail:DeleteTrail in the workload OUs, plus log delivery to a separate account nobody in the workload OU can write to.

"Account per team or account per environment?" → Both, as a grid. Then discuss where you would collapse cells and why - the answer that shows judgement is the one that names a cost of splitting, not just a benefit.

Practice

Exercise: Starter. List the resources currently in your management account, if you have one. Everything that is not billing or Organizations configuration is a finding.

Intermediate. Write an SCP that denies all actions outside two named Regions, then list every service that would break because its endpoint is global or Region-pinned.

Advanced. Design the account structure for a company with three product lines, a data platform team, a regulated workload requiring separate audit evidence, and 200 engineers. Justify every OU, state which SCPs apply where, and identify the two places you deliberately chose not to split.