AWS Cloud Practitioner Study Notes · Part 54
AWS Organizations: Multi-Account Governance, OUs, and SCPs
AWS Cloud Practitioner study notes explaining AWS Organizations, management and member accounts, OUs, SCP guardrails, consolidated billing, and account governance.
Managing one AWS account is straightforward. Managing separate development, production, security, and finance accounts is a governance problem. AWS Organizations gives a company one place to organise those accounts, consolidate billing, and apply controls at scale.
This is Part 54 of the AWS Cloud Practitioner Study Notes. The simplest mental model is:
AWS Organization
↓
Organizational Units (OUs)
↓
Member accounts
↓
Policies, billing, and governanceAWS Organizations does not merge accounts into one large account. Each member account remains an independent security and resource boundary; the organisation adds central governance around those accounts.
Why use multiple AWS accounts?
An organisation could put every team in one account, but separate accounts provide useful boundaries:
- Production resources are isolated from experiments.
- Different teams can have separate administrators and workloads.
- Security and audit data can be separated from application accounts.
- Costs can be attributed to teams or environments.
- Account-level limits and operational failures have a smaller blast radius.
- Policies can be applied to a whole group of accounts.
For example, a company might create accounts for development, testing, production, security, logging, networking, and shared services. The account structure should reflect governance and isolation needs, not merely reproduce the company’s org chart.
The organization hierarchy
An organization has a management account, a root, organizational units, and member accounts:
Organization
├── Root
│ ├── Production OU
│ │ ├── Production account
│ │ └── Database account
│ ├── Development OU
│ │ ├── Development account
│ │ └── Sandbox account
│ └── Security OU
│ ├── Audit account
│ └── Log archive accountManagement account
The management account creates and manages the organization, invites or creates accounts, manages organization policies, and pays the consolidated bill. It is a highly privileged account and should be used for organization-level tasks rather than ordinary application workloads.
AWS documentation formerly used the term “master account.” The current term is management account.
Member accounts
Member accounts are the other AWS accounts in the organization. They still have their own:
- IAM policies and roles
- VPCs and networking
- EC2 instances and databases
- S3 buckets and other resources
- Account-level service configuration
Being a member does not remove account isolation. Central policies can restrict what identities in a member account may do, but the account still owns and operates its resources.
Organizational units
An organizational unit (OU) is a container for accounts. OUs let you attach policies to a group instead of repeating the same policy on every account. An account can be placed in one OU at a time, and OUs can be nested when a deeper hierarchy is useful.
For example, a policy that restricts production accounts to approved Regions can be attached to the Production OU. New accounts moved into that OU inherit the applicable control.
Service Control Policies (SCPs)
SCPs are the most important AWS Organizations exam concept. An SCP defines the maximum available permissions for IAM users and roles in member accounts. It is a guardrail, not a permission grant.
Effective access
= IAM or resource policy permissions
AND applicable SCP permissionsSuppose an administrator in a member account has AdministratorAccess, but an SCP denies ec2:RunInstances in us-east-1. The administrator still cannot launch an EC2 instance there because the organization-level guardrail blocks the action.
Example deny guardrail:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyEC2InRestrictedRegion",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestedRegion": "us-east-1"
}
}
}
]
}This example is a study illustration, not a complete production policy. Region restrictions often need to account for global services, required exceptions, and the actions needed by security and deployment tooling.
Remember the two rules:
- An SCP never grants access by itself. The IAM or resource policy must still allow the action.
- SCPs affect member accounts, including their IAM users and roles. They do not restrict users or roles in the management account.
SCPs can be attached to the organization root, an OU, or an individual account. A member account receives the applicable controls inherited through its path in the hierarchy. Test policies carefully before attaching restrictive controls broadly.
Consolidated billing
AWS Organizations can consolidate billing and payment for multiple accounts:
Development account ─┐
Production account ──┼── Management account pays one consolidated bill
Security account ──┘Resources and account ownership remain separate, but the management account receives the consolidated bill. The organization can also combine usage across accounts for eligible volume pricing, Reserved Instance discounts, and Savings Plans benefits, subject to the applicable sharing settings and terms.
This is why the exam answer for “one bill for several AWS accounts” is usually AWS Organizations with consolidated billing.
For detailed cost analysis, use billing tools such as Cost Explorer, AWS Budgets, and the Cost and Usage Report. Organizations provides the multi-account structure and consolidated payment; it is not itself a cost dashboard.
See AWS cost and billing fundamentals for the related billing workflow.
Creating and governing accounts
Organizations can create member accounts through the CreateAccount operation or the console, and accounts can be moved into an OU after creation. In a larger landing-zone implementation, AWS Control Tower’s Account Factory can add a more complete account-provisioning workflow with approved baselines and guardrails.
Account creation is only the beginning. A useful account baseline may include:
- Central IAM Identity Center access
- CloudTrail logging to a protected log archive
- AWS Config recording and rules
- GuardDuty and Security Hub administration
- Required tags and cost allocation settings
- Network and DNS foundations
- Backup and encryption defaults
AWS Organizations provides the account governance layer. The other services provide identity, logging, compliance, security findings, networking, and backup capabilities.
Organizations and IAM Identity Center
AWS Organizations manages the account structure. IAM Identity Center manages workforce sign-in and access assignments across that structure.
Employee
↓
IAM Identity Center sign-in
↓
Permission set
↓
Role in a selected member accountOrganizations answers: “Which accounts belong to the company, and what central controls apply?”
IAM Identity Center answers: “Which employee or group can sign in to which account, with which permission set?”
They work together, but they are not interchangeable. Organizations does not replace IAM, and it does not automatically create workforce permissions.
Organization-wide security and operations
Organizations can be integrated with AWS services that support centralized administration. Common examples include:
| Service | Organization-wide use |
|---|---|
| AWS CloudTrail | Create an organization trail that records activity across accounts |
| AWS Config | Aggregate configuration and compliance data across accounts and Regions |
| Amazon GuardDuty | Delegate a security account to manage threat detection findings |
| AWS Security Hub | Aggregate security findings into a central view |
| IAM Identity Center | Provide workforce access to multiple accounts |
| AWS Backup | Apply centrally managed backup policies where supported |
These integrations require service-specific setup, delegated administrator configuration, and Regional considerations. Organizations provides the central account relationship; it does not automatically configure every service.
Organizations versus related services
| Service | Main responsibility | Typical question |
|---|---|---|
| IAM | Permissions for identities and resources in an account | What can this role do? |
| IAM Identity Center | Workforce sign-in and permission sets across accounts | Which employee can access this account? |
| AWS Organizations | Multi-account structure, governance, and consolidated billing | How should the company manage its accounts? |
| SCP | Maximum permission guardrail for member accounts | What must these accounts never do? |
| AWS Config | Resource configuration and compliance | Is this resource configured correctly? |
| CloudTrail | API activity history | Who called this API? |
| AWS Control Tower | Landing-zone orchestration on top of Organizations | How do we provision and govern accounts with a baseline? |
The distinction is important: IAM grants permissions, while SCPs limit the maximum permissions available to member-account principals. Organizations is the service that provides the hierarchy where those SCPs and account-level governance controls are managed.
What do you manage?
AWS manages the underlying Organizations service. You manage:
- The management account and organization structure
- OUs and account placement
- Account creation and invitations
- SCPs and other supported organization policies
- Billing configuration and account access
- Delegated administrators and service integrations
- The security and operational baseline for member accounts
Protect the management account carefully. Limit access, avoid running ordinary workloads there, and use delegated administration where appropriate. A mistake at the organization level can affect many accounts at once.
Common exam questions
You need one consolidated bill for multiple AWS accounts.
Use AWS Organizations with consolidated billing.
You need separate Dev, Test, and Production accounts with central governance.
Use AWS Organizations and group accounts with OUs.
An administrator has AdministratorAccess but cannot perform an action.
Check for an SCP or another policy layer that denies or does not allow the action. An SCP can restrict member-account permissions, but it cannot grant access.
You want to apply a restriction to every account in the Development group.
Place the accounts in a Development OU and attach the appropriate SCP to that OU.
You need employees to sign in once and access several AWS accounts.
Use IAM Identity Center, integrated with AWS Organizations.
You need centralized AWS account provisioning with a landing-zone baseline.
Consider AWS Control Tower Account Factory, which builds on AWS Organizations.
Final memory map
AWS Organizations
├── Management account → central administration and consolidated billing
├── Organizational Units → group accounts
├── Member accounts → separate resource and security boundaries
├── SCPs → maximum permission guardrails
└── Service integrations → centralized governance and securityThe one-sentence takeaway is: AWS Organizations centrally manages multiple independent AWS accounts, while OUs and SCPs provide structure and guardrails and consolidated billing combines their payment.