L17. AWS Organizations, SCPs & Multi-Account Guardrails

Centralized Management Across Many Accounts

AWS Organizations provides centralized management for a fleet of AWS accounts, consolidating billing into a single invoice and letting a management account apply policy consistently everywhere. Accounts are grouped into Organizational Units (OUs), and OUs are what policies actually target: service control policies (SCPs), tag policies, and backup policies attach to an OU (or directly to an account) and then apply to every account nested underneath it.

The One Account SCPs Cannot Touch

SCPs apply to OUs and member accounts, but never to the management account itself. There is no way to attach an SCP that restricts what the management account's principals can do, which means the management account has no ceiling above IAM. That is exactly why it needs the strongest independent protection available: hardware MFA on the root user, no routine workloads or human logins, and tightly scoped IAM policies for the few people who need access. A compromised member account is contained by the SCPs wrapped around its OU; a compromised management account is not contained by anything the organization itself can enforce.

Control Tower: Preventive vs. Detective Guardrails

AWS Control Tower automates the setup of a multi-account "landing zone," complete with a pre-built OU structure, logging, and a library of guardrails you enable per OU. Guardrails come in two flavors that map directly to two different AWS services:

A preventive guardrail stops an API call outright: an account simply cannot disable CloudTrail if a preventive guardrail denies it. A detective guardrail does not block anything; it continuously checks resource state and reports when something drifts out of compliance, such as an S3 bucket becoming public.

A Recommended Account Structure

A mature multi-account design separates responsibilities by account:

• Management account: used only for billing and organization administration, never for workloads.
• Security tooling and log-archive accounts: hold aggregated GuardDuty findings, Security Hub data, and centralized CloudTrail/Config logs, with access restricted to the security team.
• Per-workload or per-environment accounts: each application or environment gets its own account, so a compromise in one cannot laterally reach another and the blast radius stays contained.

Delegated Administrator: Keeping the Management Account Out of Daily Operations

Many org-wide security services (GuardDuty, Security Hub, and Macie among them) support delegated administrator: a member account (never the management account) can be designated to administer that service across the entire organization. Security teams enable, configure, and view findings from the delegated administrator account instead of logging into the management account for routine security work, which shrinks how often that highest-privilege account needs to be touched at all. Exam tip: If a scenario asks what stops even an account's own administrator from taking an action, the answer is an SCP, never an IAM policy, since IAM policies inside that account can always be changed by that account's administrator. If the scenario instead mentions the management account being restricted, that is a trap: SCPs cannot apply to it.