AWS Services
AWS Organizations
Understand AWS Organizations for multi-account governance, including management accounts, member accounts, OUs, consolidated billing, policies, and delegated administration.
After this, you will understand
Organizations makes account strategy teachable: accounts stop being isolated billing containers and become a governed multi-account system.
AWS Organizations centrally groups AWS accounts, applies organization-level policies, enables supported service integrations, and consolidates billing.
Learners try to solve production isolation, billing, logging, and governance in one account with only tags and naming conventions.
Use Organizations when an environment needs multiple accounts with central billing, OUs, policy guardrails, delegated administration, and organization-wide services.
Think before readingWhy is AWS Organizations more than consolidated billing?
Reading in progress
This page is saved in your local study history so you can continue later.
Study path
Read these in order
Start with the mechanics, then move into the patterns that explain why the system is shaped this way.
Concepts Covered
- AWS Organizations
- Management account
- Member accounts
- Organizational units
- Organization root
- Consolidated billing
- All features versus consolidated billing only
- Organization policies
- Delegated administrator accounts
- Multi-account governance
- SAA-C03 exam traps
1. Plain-English Mental Model
AWS Organizations is the control plane for managing many AWS accounts together.
The simple model is:
organization -> root -> organizational units -> AWS accounts
Without Organizations, each AWS account is managed mostly on its own. With Organizations, the business can group accounts, apply policies, use one consolidated bill, enable organization-wide service integrations, and delegate security or platform administration.
This matters because serious AWS architecture usually becomes multi-account architecture. Development, staging, production, security tooling, log archive, shared networking, and sandbox workloads should not all live in the same flat account forever.
AWS Organizations gives those accounts a hierarchy and governance model.
2. Why This Service Exists
One AWS account is simple until it becomes crowded.
At first, one account can run a lab, a small application, or a personal project. Then production arrives. Then a security team needs audit logs. Then finance needs account-level cost visibility. Then developers need sandboxes. Then a regulated workload needs stronger isolation. Eventually the account becomes a shared kitchen where every team can bump into every other team.
Organizations exists because account boundaries are one of the strongest primitives in AWS.
It helps teams create a multi-account environment without losing central control. The management account owns the organization. Member accounts hold workloads. Organizational units group accounts by environment, team, security posture, or workload type. Policies apply guardrails to those groups. Supported AWS services can integrate at organization scope.
For SAA-C03, Organizations appears in questions about central management of multiple AWS accounts, consolidated billing, separating workloads or environments, applying SCPs, delegated administration, organization trails, and reducing operational overhead for governance.
3. The Naive Approach And Where It Breaks
The naive pattern is one account with labels:
one account -> prod resources, dev resources, logs, sandboxes, shared networking
Teams try to separate things with names, tags, prefixes, or manually maintained IAM policies. That works until someone with broad access changes production while working on development. It also becomes hard to answer who owns cost, which workloads are regulated, and where logs should be protected.
Another naive pattern is many accounts with no organization. That creates the opposite problem: account sprawl with separate bills, inconsistent controls, inconsistent identity access, and no central governance path.
Organizations is the middle ground. It lets teams use many accounts while still having central structure.
4. Core Primitives
An organization is the container for centrally managed accounts.
The management account creates and manages the organization. It should be protected carefully because it has broad administrative influence.
Member accounts are the accounts inside the organization.
The root is the top of the organization hierarchy.
An organizational unit, or OU, is a group of accounts. OUs can be nested, and policies attached to parent OUs can affect child OUs and accounts.
All features mode supports central policies and service integrations. Consolidated billing mode is more limited and focuses on shared billing.
Organization policies include service control policies and other policy types. SCPs are especially important for exam questions.
Delegated administrator accounts let supported services be administered from a member account instead of making the management account the daily operations account.
5. Architecture Use Cases
Use Organizations to separate development, staging, production, security, logging, networking, and sandbox accounts.
A basic production layout might be:
management account
-> Security OU
-> log archive account
-> security tooling account
-> Workloads OU
-> dev account
-> staging account
-> production account
-> Sandbox OU
-> team sandbox accounts
Use consolidated billing when many accounts should roll up to one payer while preserving account-level cost visibility.
Use SCPs to limit what member accounts can do, such as denying access to disallowed Regions or preventing logging controls from being disabled.
Use delegated administration so security services can be operated from a security account rather than from the management account.
Use organization-wide CloudTrail and Config patterns for audit and compliance.
7. Security Model
Organizations security starts with the management account.
The management account should not be used casually. Protect root credentials, enforce MFA, limit who can administer the organization, and avoid running ordinary workloads there.
SCPs can restrict maximum available permissions in member accounts, but they do not grant permissions. IAM policies still grant access inside accounts.
Policies attached higher in the hierarchy can affect many accounts at once. That is powerful and dangerous.
Delegated administrator patterns reduce day-to-day use of the management account, but delegated accounts still need careful permissions.
Centralized logging and security accounts should be isolated from application teams so audit evidence cannot be modified by the same team being audited.
8. Reliability And Resilience
Organizations improves resilience by reducing blast radius.
If a developer breaks a sandbox account, production should not be affected. If a workload account is compromised, central security tooling and log archive accounts should remain separate.
OUs help apply different controls to different risk zones. Production accounts can have stricter guardrails than experimentation accounts.
The risk is governance failure at the top. A bad policy attached to a root or major OU can break many accounts. Test policies in limited OUs before broad rollout.
Use automation for account baselines so new accounts do not start without required logs, security services, budgets, and access patterns.
9. Performance And Scaling
Organizations is not a runtime performance service. Its scaling value is organizational and operational.
It helps a company scale from a few accounts to many accounts without losing structure.
As account count grows, the key performance problem becomes governance throughput: account creation, baseline setup, identity assignment, policy testing, logging, cost allocation, and service delegation.
Use account vending, infrastructure as code, Control Tower, StackSets, and automation so new accounts are consistent.
Do not design an OU hierarchy that is too clever. OUs are policy and governance boundaries. They should map to control needs more than to every org chart nuance.
10. Cost Model
AWS Organizations itself does not add a separate charge for basic use.
The cost impact comes from centralized billing, account-level cost visibility, and services enabled across accounts.
Many governance services have their own pricing. Organization-wide CloudTrail, Config, GuardDuty, Security Hub, VPC endpoints, and logging storage can create cost.
However, Organizations also enables better cost control: separate sandbox accounts, budgets, account-level chargeback, and central cost reporting.
For the exam, consolidated billing is a common clue. The answer is Organizations when the requirement is one bill across multiple accounts.
12. SAA-C03 Exam Signals
"Centrally manage multiple AWS accounts" points to AWS Organizations.
"Consolidated billing" points to AWS Organizations.
"Apply guardrails to groups of accounts" points to Organizations plus SCPs or Control Tower.
"Separate dev, test, and prod with strong boundaries" often points to multiple accounts in an organization.
"Enable an AWS service across all accounts" can point to Organizations integration and delegated administration.
"Grant workforce users access to many AWS accounts" points to IAM Identity Center integrated with Organizations.
"Set up and govern a landing zone with best practices" points to Control Tower.
13. Common Exam Traps
Do not confuse an AWS account with an IAM user.
Do not assume consolidated billing mode gives all governance features.
Do not use the management account for regular workloads.
Do not use SCPs as permission grants. They set limits.
Do not attach broad restrictive policies to the organization root without testing.
Do not rely on tags as a substitute for account isolation.
15. Related Topics
Review AWS Account Model, Service Control Policies, AWS IAM Identity Center, AWS Control Tower, and AWS CloudTrail.
Official AWS references:
What to study next
These links keep the session moving: read prerequisites first, then open the systems, concepts, and patterns that deepen this page.
Prerequisites
Read these first if the mechanics feel unfamiliar.
More Links
Additional references connected to this page.