What is AWS Organizations? A plain-English explainer

Why companies end up with many AWS accounts

A single AWS account is a natural boundary: it is where billing, resource limits, and by default, security and access all live. As a company grows, it commonly wants separate boundaries too — one account for production, one for development, one per team or business unit — so that a mistake or a security incident in one account cannot spill into another, and so different teams cannot accidentally interfere with each other’s resources.

That is a sound practice, but it creates a new problem: dozens or hundreds of accounts, each needing to be billed, secured and governed consistently. AWS Organizations exists to manage that many-accounts reality centrally, rather than leaving each account to be administered in isolation.

Organisational units, in brief

Organizations lets you group accounts into organisational units (OUs) — nested groupings, similar in spirit to folders — so that policy can be applied to a whole group of related accounts at once rather than one account at a time. A company might, for example, group all of its production accounts under one OU and all of its development accounts under another, and then apply different rules to each group.

Service control policies: guardrails, not grants

Service control policies (SCPs) are the main governance tool in Organizations, and the detail that matters most is what they are not: an SCP never grants permissions. It sets the maximum boundary of what is allowed within an account or OU — a ceiling that IAM permissions inside that account cannot exceed, no matter how permissive those IAM policies are.

That makes SCPs a guardrail rather than a grant: even an account administrator with full IAM permissions in their own account cannot do something an SCP has placed off-limits at the organisation level. A typical use is blocking an entire category of action across every account in an OU — for example, preventing accounts from leaving the organisation, or restricting which AWS Regions can be used — centrally, once, rather than trusting every account to enforce the same rule on its own.

Consolidated billing

Organizations also rolls usage across every member account into a single bill for the whole organisation, rather than each account being invoiced separately. Beyond convenience, this means usage is combined across accounts for the purposes of any volume-based pricing benefits AWS offers, which can work out more efficiently than accounts being billed in isolation — check AWS’s own pricing pages for how that works today.

Common uses

Typical reasons companies adopt AWS Organizations include:

• Multi-account governance — applying consistent guardrails, such as blocked actions or Region restrictions, across many accounts from one place.
• Environment separation — keeping production, staging and development in genuinely separate accounts while still managing them centrally.
• Consolidated billing — one invoice and combined usage across every account in the organisation.
• Centralised security tooling — several AWS security services can be enabled organisation-wide through Organizations rather than account by account.

Where AWS Organizations appears in certification study

Organizations is core content on AWS Certified Security Specialty, where multi-account governance and SCPs are tested in depth, and it appears on AWS Certified Solutions Architect – Associate and AWS Certified CloudOps Engineer – Associate as a standard part of designing and operating a multi-account environment. Related identity and permissions concepts are covered in our what-is-aws-iam explainer.

This article covers what Organizations is and why companies use it — the syllabus depth on specific SCP syntax and organisation-wide security service configuration belongs in the exam guide itself, which our /revision study library covers lesson by lesson.