AWS Organizations

Lesson 1 of 5 in The Multi-Account Foundation.

Every account you own is a hard permissions boundary. That is the property the whole domain is built on: an IAM mistake in the sandbox account cannot reach production data, because production lives behind a different account's identity perimeter. AWS Organizations is how you get that isolation without getting chaos — one place to create accounts, group them, and lay policy across them.

The vocabulary is small and the exam uses it precisely. One account is the management account (the payer, and the only account that can create an organization). Every other account is a member account. The root is the container at the top of the hierarchy — not the root user, a different thing entirely, and the exam will put both words in one question to see whether you flinch. Below the root sit organizational units, which nest up to five levels deep, and accounts live in exactly one OU at a time.

An organization runs in one of two modes. All features is the real one: policies, delegated administration, every integration. Consolidated billing only does what the name says — one bill, no policy control. Almost every security capability in this domain requires all features, so the first troubleshooting question when a policy type will not enable is always which mode is this organization in?

A five-layer stack of an AWS organization, bottom to top. Bottom layer: the management account — billing, the organization itself, policy attachment, and nothing else; no workloads, no data, and SCPs do not restrict it. Second layer, emphasized: the Security OU, containing a dedicated security tooling account (delegated administrator for Security Hub, GuardDuty, Config, Inspector, Macie and Detective) and a log archive account (holding the organization CloudTrail bucket and Config history under Object Lock, with no human write access). Third layer: the Infrastructure OU — shared networking, Transit Gateway, Private CA, shared service endpoints. Fourth layer: Workloads OU, nested into Prod and Non-prod child OUs so a policy can differ by environment. Top layer: Sandbox and Suspended OUs — permissive experimentation and quarantined accounts, each with its own policy posture.

The structure the exam assumes. Read it bottom-up: the management account holds almost nothing, and the security capabilities live one layer down. (illustrative — source: AWS Organizations — best practices for the management account)

Accounts arrive two ways. Create them from the organization (CreateAccount, or Control Tower's Account Factory) and they are born inside it, with a role named OrganizationAccountAccessRole already trusting the management account — that is how the management account administers a new member without a root password. Invite an existing account and it joins by accepting; the invited account keeps whatever it already had, and crucially it gets no OrganizationAccountAccessRole unless you create one yourself. The exam asks this as "we invited the account and now cannot administer it" — the answer is to create the cross-account role, not to blame Organizations.

Two integration concepts carry the rest of the domain. Trusted access is the organization-level switch that lets an AWS service read your organization structure and operate across member accounts; without it, "enable this for the whole organization" simply is not offered. Delegated administration then nominates which member account drives that service org-wide. The pair is the standard answer to any "centrally manage X across all accounts" question, and the next-to-last lesson in this module walks it service by service.

Service-linked roles are the plumbing underneath: Organizations creates AWSServiceRoleForOrganizations in each member account so integrated services can act there. You cannot usefully restrict these — and, as the SCP lesson will show, you cannot restrict them with an SCP even if you try.

The four accounts every SCS-C03 scenario assumes — and the sentence that gives each one away
Account	What runs there	What must never run there	The exam tell
Management	The organization, policy attachment, consolidated billing, the Control Tower landing zone	Workloads, production data, day-to-day human access, security tooling you could delegate	“Reduce the blast radius of the organization’s most privileged account” — move things out of it
Security tooling	Delegated administrator for Security Hub, GuardDuty, Config, Inspector, Macie, Detective, Access Analyzer; the responders’ roles	Application workloads — it is a control plane, not a tenant	“Centrally view findings from all accounts”, “a dedicated security account”
Log archive	The organization trail’s S3 bucket, Config history and snapshots, VPC flow logs — ideally with Object Lock and a separate KMS key	Anything with interactive write access, including the security team’s own tooling	“Logs must survive compromise of the account that produced them”, “immutable”, “tamper-proof”
Workload	One application, one environment. Prod and non-prod are different accounts, not different tags	Shared infrastructure other teams depend on; organization-wide tooling	“Isolate the breach to one application”, “separate duties between environments”

Interactive sorting exercise: Which account should own each capability?

Key terms: AWS Organizations, Management account, Organizational unit (OU), All features mode, Trusted access, OrganizationAccountAccessRole

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.