AWS Organizations and multi-account strategy

A single AWS account is simple, but that simplicity has a real cost as things grow: a mistake in a "just testing something" experiment can affect production resources sitting in the same account; every IAM permission has to be scoped carefully within one shared space instead of relying on account boundaries; and billing for genuinely different purposes (a dev environment, a production environment, a separate team's project) is all mixed into one bill with no natural separation. AWS Organizations is AWS's answer: a structure for managing multiple accounts centrally, under one management account, with policies that can apply across all of them at once.

An Organizational Unit (OU) groups accounts so policies can be applied to the whole group at once, rather than account by account. A common, simple starting structure: a "Production" OU and a "Non-Production" OU, each with different guardrails — production might block the ability to disable CloudTrail logging entirely, while non-production allows more experimentation.

A Service Control Policy (SCP) attached to an OU (or individual account) sets the maximum permissions available to every identity in that account — even an account's own root user cannot exceed what an SCP allows, since SCPs apply above and outside normal IAM entirely. This is the organization-wide equivalent of the permissions boundary concept from this domain's IAM lesson, just scoped to entire accounts instead of individual roles.

Attached to the "Production" OU, this SCP makes it impossible for anyone in a production account — including someone with an otherwise-admin IAM role — to disable audit logging, no matter what IAM policy they're granted directly. SCPs are for org-wide guardrails that must never be bypassable by a permissions mistake in an individual account, not for day-to-day permission management (that's still IAM's job within each account).

The natural first question: why go through the complexity of multiple accounts instead of just being careful with IAM roles and tagging within a single account? A few concrete reasons this curriculum's earlier lessons already set up the vocabulary for:

Accessing resources across accounts uses the same IAM role-assumption pattern from this domain's IAM lesson, extended across account boundaries — a role in Account B can trust Account A, allowing a user or service in Account A to assume it and temporarily act within Account B, with no credentials ever copied between accounts.

For a team just beginning to split beyond a single account, a reasonable minimal structure: a management account (billing and org-level policies only, no actual workloads run here), a production account, and a dev/staging account — three accounts, not the elaborate 10+-account structures larger enterprises eventually grow into. The structure should grow as real organizational needs emerge (a genuinely separate team needing its own account, a compliance requirement demanding account-level isolation), not be over-built speculatively from day one — the same "match the structure to actual need" principle the Agile & Project Management domain's scaling-agile lesson makes about organizational frameworks generally.