What Is AWS Organizations? Accounts, OUs, SCPs Explained

Simple explanation

Think of AWS Organizations like a company org chart, but for AWS accounts instead of people. There is one headquarters (the management account) that oversees everything, departments (OUs) that group teams together, and company-wide policies (SCPs) that flow from the top down.

The whole model comes down to five pieces:

• One management account that created the organization. It handles billing and administrative control. You do not run workloads here.
• Multiple member accounts, each a fully separate AWS environment with its own IAM, resources, and security boundary.
• Organizational Units (OUs) for grouping accounts. You might have a “Production” OU, a “Security” OU, and a “Non-Production” OU.
• Service Control Policies (SCPs) that cap what any account or OU can do. SCPs restrict permissions but never grant them. Attach one to an OU and every account inside inherits that restriction.
• One consolidated bill so all accounts share a single payment method. Usage across accounts combines toward volume pricing tiers, and Reserved Instances can apply across accounts.

Why teams use AWS Organizations

A single AWS account is like one big open-plan office. Everyone shares the same space, the same budget line, and the same security perimeter. A developer who accidentally deletes a database table could wipe out production data. A billing spike from one team’s experiment hits the whole company. A compromised application puts every resource at risk.

Multiple accounts fix this by giving each team or environment its own locked room. Resources in one account are invisible to another account unless you explicitly set up cross-account access through role assumption. There is no accidental path from dev to production.

Organizations makes multi-account setups practical:

• Account isolation: a misconfigured security group in a dev account cannot affect a production account. The blast radius of any mistake or breach stays contained.
• Centralized governance: instead of configuring guardrails account by account, you apply Service Control Policies once at the OU level. Every account underneath inherits the restriction.
• Cost visibility: consolidated billing gives you one invoice, but Cost Explorer still breaks spending down per account. You can see exactly how much each team or environment costs without tagging gymnastics.
• Compliance and separation of duties: regulated workloads (HIPAA, PCI-DSS, SOC 2) can live in dedicated accounts with stricter controls, while less sensitive workloads stay in separate accounts with lighter guardrails.
• Blast radius reduction: if an attacker compromises one account, they get that account’s resources only. They cannot pivot to other accounts without explicitly granted cross-account access.

For a broader view of where account isolation fits in the AWS security model, see the shared responsibility model.

How AWS Organizations works

Management account

The management account is the account that created the organization. It is the only account that can create or remove member accounts, manage OUs, attach SCPs, and view the consolidated bill. Think of it as the building manager who holds the master keys but does not live in any of the apartments.

Here is the critical detail most beginners miss: SCPs do not apply to the management account itself. Any SCP you attach at the Root or OU level restricts member accounts but not the management account. This is the single biggest reason to keep the management account empty of workloads. You simply cannot enforce guardrails on it the same way you can on member accounts.

Member accounts

Every account other than the management account is a member account. Each member account is a fully independent AWS environment with its own IAM users and roles, its own resources, and its own root user. Member accounts are subject to SCPs applied at the OU or Root level above them.

You can create new member accounts directly from the management account, or invite existing standalone accounts to join. Invited accounts keep their existing resources and configuration. They simply gain an organizational relationship and become subject to SCPs.

Root and Organizational Units (OUs)

Every organization has a single Root, the top-level container. Below the Root, you create Organizational Units (OUs) to group accounts by purpose. OUs can be nested, so you can build a hierarchy that mirrors your company structure.

Policies applied to an OU inherit downward. If you attach a deny-region SCP to the Production OU, every account inside that OU (and every account inside any child OU) inherits the restriction. This makes OUs the natural grouping mechanism for governance. See restricting resource locations for a practical example of region restriction SCPs.

Service Control Policies (SCPs)

Service Control Policies are the governance tool in Organizations. An SCP defines the maximum permissions any identity in a member account can have, including administrators and even the root user of that member account.

A good analogy: IAM policies are like giving someone a keycard to specific rooms in a building. SCPs are like locking certain floors entirely. Even if your keycard works for every room on floor 5, the SCP that locks floor 5 means you cannot get there at all.

Two things beginners commonly misunderstand:

1. SCPs restrict but never grant. An SCP that allows s3:* does not give anyone S3 access. It means S3 actions are not blocked by the SCP. The principal still needs an IAM policy that explicitly grants the action. SCPs and IAM work through intersection: both must allow the action.
2. SCPs do not apply to the management account. Every SCP you create only restricts member accounts. The management account is always exempt. This is not configurable.

The difference between IAM and Organizations is straightforward: IAM controls who can do what inside a single account. Organizations controls what entire accounts are allowed to do. IAM is the permissions layer. SCPs are the guardrails layer. Both must allow an action for it to succeed, following the principle of least privilege.

Consolidated billing

All accounts in the organization share a single payment method attached to the management account. The management account receives one consolidated bill. Two practical benefits come from this:

• Volume pricing: usage across all accounts aggregates toward AWS pricing tiers. Ten accounts each using 100 GB of S3 get priced as 1 TB, not ten separate 100 GB buckets.
• RI and Savings Plan sharing: Reserved Instances and Savings Plans purchased in any account can apply to matching usage in other accounts, maximizing utilization.

Each account still appears separately in Cost Explorer. You get one bill but full per-account visibility. For more on cost management, see how billing works.

Delegated administration

You do not have to log into the management account for day-to-day operations. AWS lets you delegate administration of specific services (like AWS Config, Security Hub, or GuardDuty) to a designated member account. Your security team can manage Security Hub from a dedicated security account instead of needing management account access.

How it works in practice

Here is the typical workflow from “I have one account” to “I have a governed multi-account setup”:

1. Create or invite accounts. Start by creating dedicated accounts for your core needs: a security/audit account, a log archive account, and at least one workload account per environment.
2. Group accounts into OUs. Create OUs that reflect how you govern. Typically this means Security, Infrastructure, and Workloads OUs. Under Workloads, separate Production and Non-Production.
3. Apply baseline guardrails with SCPs. Attach SCPs at the Root level that apply everywhere: deny leaving the organization, deny disabling CloudTrail, deny creating resources in unapproved regions. These are your non-negotiable safety nets.
4. Set up security and log archive accounts. Route CloudTrail logs, AWS Config data, and GuardDuty findings to a centralized log archive account. Run security tooling from a dedicated security account.
5. Enable cross-account access with roles. Use role assumption for access between accounts. Use the aws:PrincipalOrgID condition key in trust policies so new accounts automatically get access without policy updates.
6. Monitor and govern centrally. Use delegated administration to run Security Hub, AWS Config, and GuardDuty from your security account. Review the consolidated bill and per-account spending regularly.

Example AWS Organizations structure

Here is a realistic account layout for a small-to-mid-sized company. Notice how the structure mirrors governance boundaries, not team reporting lines:

Root (management account: org-management@company.com)
│
├── Security OU
│   ├── log-archive       (centralized CloudTrail, Config, and access logs)
│   └── security-tooling  (Security Hub, GuardDuty, delegated admin)
│
├── Infrastructure OU
│   ├── shared-networking  (Transit Gateway, DNS, VPN)
│   └── shared-services    (CI/CD tooling, container registries)
│
└── Workloads OU
    ├── Production OU
    │   ├── prod-api       (backend services)
    │   └── prod-frontend  (web application)
    │
    └── Non-Production OU
        ├── dev-api        (development environment)
        ├── staging-api    (pre-production testing)
        └── sandbox        (experimentation, strict budget alerts)

In this layout, SCPs on the Production OU enforce stricter controls (deny unapproved regions, deny deleting critical resources), while Non-Production accounts have lighter guardrails to allow experimentation. The Security OU accounts are locked down tightly and managed by a dedicated team.

When to use AWS Organizations

Many teams start with a single AWS account and eventually hit its limits. Here are the clearest signals that you need Organizations:

If any of these situations apply, Organizations is the right tool. If you only have one account and one small team, you may not need it yet, but plan for it.

AWS Organizations vs IAM vs Control Tower

These three services are commonly confused because they all relate to access control and governance. The simplest way to think about them: Organizations is the building, IAM is the lock on each door, and Control Tower is the property management company that sets up the building for you.

For teams just starting with multiple accounts, Organizations alone is enough. Add Control Tower later if you want automated account vending and pre-built guardrails. To understand the IAM side in depth, see the IAM overview.

CLI examples

Create a new member account

Account creation is asynchronous. You get a request ID to check the status.

aws organizations create-account \
  --email prod-api@company.com \
  --account-name "prod-api"

Check the creation status:

aws organizations describe-create-account-status \
  --create-account-request-id car-exampleid

List all accounts in the organization

aws organizations list-accounts \
  --query 'Accounts[*].[Name,Id,Status]' \
  --output table

Move an account to an OU

# Find the Root ID and OU IDs
aws organizations list-roots
aws organizations list-organizational-units-for-parent \
  --parent-id r-xxxx

# Move the account
aws organizations move-account \
  --account-id 123456789012 \
  --source-parent-id r-xxxx \
  --destination-parent-id ou-xxxx-yyyyyyyy

Attach an SCP to an OU

aws organizations attach-policy \
  --policy-id p-examplescpid \
  --target-id ou-xxxx-yyyyyyyy