AWS Organizations: Complete Implementation Guide (2026)

As you scale your AWS usage beyond a single account, managing users, security, billing, and compliance across multiple accounts becomes increasingly complex. AWS Organizations solves this by providing centralized management and governance for your entire AWS environment from a single interface.

In this guide, you'll learn everything you need to know about AWS Organizations: how it works, the key features including new 2024-2025 capabilities like Resource Control Policies (RCPs) and declarative policies, how to structure your organization, and how to implement governance at scale.

What is AWS Organizations?

AWS Organizations is a free account management service that enables you to centrally manage and govern multiple AWS accounts. It's a global service with a single endpoint that forms the foundation of any AWS Cloud Foundation and is essential for building a secure, scalable landing zone.

An organization consists of a hierarchical structure containing:

• Management account: The AWS account that creates the organization, has full administrative control, and pays all member account charges
• Member accounts: AWS accounts that belong to the organization and are subject to organizational policies
• Organizational Units (OUs): Logical containers for grouping accounts based on security, compliance, or business requirements
• Policies: JSON documents that define permissions, configurations, or operational rules

Core Components and Terminology

Root: The parent container for all accounts and OUs in an organization. Every organization has exactly one root, automatically created during setup. The root is not an OU itself but sits at the top of the hierarchy.

Management Account: This account has full control over the organization. It pays all charges for member accounts and cannot have Service Control Policies (SCPs) or Resource Control Policies (RCPs) applied to it. Critical point: The management account cannot be changed once established, and AWS recommends not using it for business workloads.

Member Accounts: AWS accounts that belong to the organization. Each account can only belong to one organization at a time. Member accounts can be created within the organization or invited to join from outside.

Organizational Units (OUs): Containers that group accounts for policy application. OUs can nest up to 5 levels deep, and policies attached to an OU apply to all accounts and child OUs beneath it through inheritance.

Why Organizations Matter for Multi-Account Strategy

A multi-account strategy isn't just a nice-to-have for growing organizations. It's how you achieve:

• Security isolation: Compromises in one account don't automatically spread to others
• Independent service quotas: Each account gets its own quotas, preventing one workload from starving another
• Simplified cost allocation: Track spending by account rather than parsing complex tag-based allocations
• Compliance boundaries: Isolate regulated workloads (PCI-DSS, HIPAA) in dedicated accounts
• Blast radius reduction: Limit the impact of misconfigurations or security incidents

AWS Organizations makes multi-account architecture practical by providing the centralized governance, billing consolidation, and policy enforcement needed to manage accounts at scale.

Organizations vs Control Tower vs Landing Zone

These three concepts are related but distinct:

Think of it this way: Organizations is the foundation, Control Tower is one way to automate building on that foundation, and a landing zone is the finished structure of your cloud foundation. For a comprehensive view of how all these components work together, see our complete guide to AWS Cloud Foundations.

Key Features and Capabilities

Consolidated Billing and Cost Management

AWS Organizations automatically enables consolidated billing. The management account receives a single bill covering all member accounts, with several cost benefits:

• Volume discounts: Combined usage across accounts qualifies for tiered pricing on services like S3, Data Transfer, and EC2
• Shared reservations: Savings Plans and Reserved Instances purchased in one account can apply across the organization
• Free tier sharing: The AWS Free Tier applies to total organization usage, not per account
• Cost allocation: Use tags and Cost Categories to attribute spending back to business units or projects

Hierarchical Account Organization with OUs

OUs let you group accounts based on common policy requirements. Key specifications:

• Maximum 5 levels of nesting under the root
• Maximum 2,000 OUs per organization
• Policy inheritance: Policies flow down from parent to child, affecting all accounts beneath

This hierarchical structure is powerful because you can apply a policy once at an OU level and have it automatically apply to hundreds of accounts beneath it.

Policy-Based Governance (SCPs, RCPs, Declarative)

AWS Organizations supports multiple policy types for different governance needs:

Authorization Policies (set maximum permissions):

• Service Control Policies (SCPs): Principal-centric controls limiting what IAM users and roles can do
• Resource Control Policies (RCPs): Resource-centric controls limiting what can be done to your resources (new in 2024)

Management Policies (configure services and features):

• Declarative Policies: Enforce configurations for EC2, EBS, and VPC (new in 2024)
• Backup Policies: Automate backup plans across accounts
• Tag Policies: Standardize tagging across resources
• AI Services Opt-Out Policies: Control data collection for AWS AI services

Service Integrations and Delegated Administrators

AWS Organizations integrates with 250+ AWS services through trusted access and delegated administrators. This enables features like:

• Organization-wide CloudTrail trails
• Centralized Security Hub findings
• Cross-account AWS Config rules
• Organization-wide GuardDuty threat detection

Learn more about setting up these integrations in Why AWS Delegated Administrators Are Essential.

2024-2025 New Features Overview

AWS has significantly enhanced Organizations in recent releases:

• Resource Control Policies (November 2024): A new authorization policy type for resource-centric controls, supporting S3, STS, KMS, SQS, Secrets Manager, ECR, and OpenSearch Serverless
• Declarative Policies (December 2024): Enforce configurations for EC2, EBS, and VPC services at scale
• Direct Account Transfers (November 2025): Transfer accounts between organizations without removing them first
• Root Access Management: Centrally manage root credentials for all member accounts
• Full IAM Language Support for SCPs: Enhanced SCP capabilities with complete IAM policy language

Understanding Organizational Structure

Organizational Units (OUs) Explained

OUs are policy containers. While you can organize them to mirror your business structure, the real value is grouping accounts that need the same policies together, even if they're from different business units.

Key characteristics:

• OUs can contain both accounts and other OUs
• OU names must be unique within their parent
• Policies attached to an OU automatically apply to everything beneath it
• Moving an account to a different OU immediately changes which policies apply

Real-World OU Architecture Patterns

AWS recommends starting with foundational OUs that most organizations need:

• Security OU: Houses audit accounts and security tooling
• Infrastructure OU: Contains shared services like networking and directory services

Beyond these, common additional OUs include:

• Sandbox: Relaxed controls for experimentation
• Workloads: Production applications, often with nested Prod/Dev OUs
• Policy Staging: For testing policy changes before broader rollout
• Suspended: Holds closed accounts during the post-closure period
• Transitional: For accounts moving between OUs during restructuring

For comprehensive architecture patterns based on organization size, see AWS Multi-Account Strategy.

OU Design Best Practices

1. Treat OUs as policy containers: Group accounts by policy requirements, not just org chart structure
2. Apply policies at OU level: Easier to manage than account-by-account policies
3. Minimize nesting: While 5 levels are allowed, 2-3 levels are often easier to manage and troubleshoot
4. Plan for evolution: OU structures evolve as your cloud adoption matures
5. Use inheritance strategically: Place common restrictions at higher levels, specific ones at lower levels

Setting Up AWS Organizations

Prerequisites and Planning

Before creating an organization:

1. Secure your management account: Enable MFA on the root user, verify the email is business-managed (not personal), and document existing resources
2. Plan your OU structure: Sketch out which OUs you need based on policy requirements
3. Identify policy requirements: Know which SCPs, RCPs, and management policies you'll need
4. Plan service integrations: Determine which services (CloudTrail, Config, Security Hub) you'll enable organization-wide
5. Communicate changes: Inform stakeholders about upcoming governance changes

Quick Setup Steps

To create an organization:

1. Navigate to AWS Organizations in the console
2. Click Create an organization
3. Your current account becomes the management account
4. Enable "all features" (not just consolidated billing) to access SCPs, RCPs, and delegated administrators
5. Enable all policy types in the Policies section
6. Create your foundational OUs (Security, Infrastructure at minimum)

Important: The account you use to create the organization becomes the management account permanently. Choose wisely.

Next Steps

After basic setup, you'll want to configure critical settings that most teams miss. For comprehensive guidance on enabling all 8+ policy types, setting up 15+ service integrations, and configuring delegated administrators, see AWS Organizations Best Practices.

Implementing Governance with Policies

Service Control Policies (SCPs) Overview and Examples

SCPs are principal-centric guardrails that set the maximum permissions available to IAM users and roles in member accounts. Key points:

• SCPs do not grant permissions. They only limit them
• They affect all principals in attached accounts, including the root user
• They do not affect the management account or service-linked roles
• Maximum 5 SCPs per OU or account, 5,120 characters per policy

Common SCP use cases:

• Restrict operations to specific AWS regions
• Require MFA for sensitive operations
• Prevent modification of security controls (CloudTrail, Config)
• Block access to non-approved services

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAllOutsideAllowedRegions",
      "Effect": "Deny",
      "NotAction": [
        "iam:*",
        "organizations:*",
        "support:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": ["eu-west-1", "eu-central-1"]
        }
      }
    }
  ]
}

For a comprehensive library of production-ready policies, see AWS SCP Examples by OU and AWS Service Control Policies Guide.

Resource Control Policies (RCPs) - New in 2024

RCPs are a major addition to Organizations, launched in November 2024. While SCPs control what principals can do, RCPs control what can be done to your resources, regardless of whether the request comes from inside or outside your organization.

Supported services (at launch):

• Amazon S3
• AWS STS
• AWS KMS
• Amazon SQS
• AWS Secrets Manager
• Amazon ECR
• Amazon OpenSearch Serverless

Key differences from SCPs:

• SCPs limit permissions granted to principals within the organization
• RCPs limit permissions granted to resources in the organization
• RCPs affect external principals accessing your resources
• Both can be used together for comprehensive data perimeters

Common RCP use cases:

• Prevent external access to S3 buckets (data perimeter)
• Require HTTPS/TLS for all resource access
• Enforce minimum TLS versions
• Prevent public access to sensitive resources

Declarative Policies - New in 2024

Declarative policies (December 2024) let you centrally enforce configurations for EC2, EBS, and VPC services. Unlike SCPs that block actions, declarative policies enforce a desired state that's automatically maintained.

Supported policies at launch:

1. VPC Block Public Access: Controls internet gateway access
2. Serial Console Access: Manages EC2 serial console access
3. Image Block Public Access: Controls AMI sharing
4. Allowed Images Settings: Restricts which AMIs can be used
5. Instance Metadata Defaults: Enforces IMDSv2
6. Snapshot Block Public Access: Prevents public EBS snapshot sharing

The power of declarative policies is that they're durable: they apply regardless of whether someone uses the console, CLI, SDK, or CloudFormation, and they automatically cover new APIs that AWS adds.

Tag Policies and Backup Policies

Tag Policies standardize tagging across your organization:

• Define acceptable tag keys and values
• Enforce case treatment
• Prevent non-compliant tagging operations
• Maximum 10 per OU or account, 10,000 characters each

Backup Policies automate backup plans:

• Define backup frequency, retention, and lifecycle rules
• Specify target backup vaults and regions
• Select resources by tags or resource types
• Effective backup policies appear in AWS Backup console

Testing and Deploying Policies Safely

Policy mistakes can break production workloads. Follow these practices:

1. Use a Policy Staging OU: Create a dedicated OU for testing policy changes with non-production accounts
2. Test with one account first: Move a single test account, validate, then expand
3. Review service last accessed data: IAM shows which services are actually being used before you restrict them
4. Use IAM Access Analyzer: Analyze the impact of policy changes before deployment
5. Implement progressively: Start with audit mode or less restrictive versions, then tighten
6. Document rationale: Future you will thank present you for explaining why each policy exists

Service Integrations and Trusted Access

Enabling Trusted Access and Delegated Administrators

AWS Organizations integrates with 250+ services through two mechanisms:

Trusted Access: Grants a service permission to create service-linked roles in every account, enabling organization-wide operations.

Delegated Administrator: Designates a member account to manage a service across the organization, reducing reliance on the management account.

Best practice is to always use delegated administrators when available. This keeps your management account clean and reduces its risk exposure. For implementation details, see Why AWS Delegated Administrators Are Essential.

Critical Security Integrations

These services should be enabled organization-wide from day one:

AWS CloudTrail: Organization trails log API activity across all accounts to a centralized location. Essential for security investigations and compliance audits.

AWS Config: Organization-wide Config rules evaluate resource compliance across all accounts. Conformance packs enable consistent compliance frameworks (CIS, PCI-DSS).

AWS Security Hub: Centralized security findings from GuardDuty, Config, Inspector, and third-party tools. Supports up to 10,000 member accounts.

Amazon GuardDuty: Threat detection across all accounts with centralized management. Supports up to 1,200 member accounts with delegated administrator.

Cost Management Integrations

AWS Cost Explorer: Analyze costs across your entire organization with filtering by account, service, tag, or cost category.

AWS Cost Optimization Hub: Centralized recommendations for cost savings across accounts.

AWS Budgets: Set organization-wide or account-level budgets with alerts.

AWS Organizations and Control Tower

When to Use Organizations Alone vs Control Tower

Use Organizations alone when:

• You want full control over your landing zone implementation
• You're using infrastructure as code (CDK, Terraform, CloudFormation)
• You need customizations that Control Tower doesn't support
• You have experienced cloud engineers who can build and maintain governance

Use Control Tower when:

• You want AWS-managed guardrails and best practices
• You prefer console-based management over code
• You need Account Factory for self-service account provisioning
• You're starting fresh with fewer existing accounts

For alternative approaches, see AWS Control Tower Alternatives.

How Control Tower Builds on Organizations

Control Tower doesn't replace Organizations. It uses Organizations as its foundation and adds:

• Pre-configured OUs: Security OU with Log Archive and Audit accounts
• Guardrails: Pre-built controls implemented as SCPs (preventive) and Config rules (detective)
• Account Factory: Self-service portal for provisioning new accounts with approved configurations
• Dashboard: Central visibility into compliance and account status

Deploying Control Tower in Existing Organizations

You can deploy Control Tower into an existing organization:

1. Control Tower creates its structure alongside (not replacing) existing OUs
2. It adds Audit and Log Archive accounts to the Security OU
3. You can extend governance to existing OUs by registering them
4. Existing accounts are enrolled into the landing zone, applying mandatory controls

Subject to the same billing and management account structure you already have.

Consolidated Billing and Cost Optimization

How Consolidated Billing Works

Consolidated billing is automatic with Organizations. The management account:

• Receives a single bill for all accounts
• Is responsible for paying all charges
• Can view usage and charges for all member accounts

Member accounts can only see their own usage. They don't see other member accounts' spending.

Volume Discounts and Savings Strategies

AWS calculates volume discounts based on combined usage across all accounts:

• S3 storage tiers: Combined storage determines your pricing tier
• Data Transfer: Aggregated transfer qualifies for lower per-GB rates
• EC2 blended rates: Reserved Instance and On-Demand costs are averaged

Savings Plans and Reserved Instances apply organization-wide. Purchase them in one account, and they automatically apply to matching usage in any account (within the same organization).

Note: Free tier applies to total organization usage, not per account. If your free tier includes 5 GB of S3 storage, that's 5 GB across all accounts combined.

Cost Allocation and Chargeback Models

Implement cost visibility and accountability:

1. Cost allocation tags: Activate tags to track spending by project, team, or environment
2. Cost Categories: Create custom groupings for cost analysis (by business unit, application, etc.)
3. Linked account billing: Each account's costs are tracked separately
4. Chargeback/showback: Use Cost Explorer to create reports for internal billing

Tax Inheritance and Invoice Configuration

Tax inheritance simplifies tax settings across accounts. Configure once in the management account, and new accounts automatically inherit tax settings.

Invoice configuration (newer feature) allows individual business entities within your organization to be responsible for their own spend and payment, supporting decentralized billing scenarios.

Security and Compliance Best Practices

Management Account Security (Critical)

The management account is your organization's single point of control. Compromise here affects everything. Protect it accordingly:

1. Never use for workloads: The management account should only be used for organizational management
2. Enable MFA everywhere: Root user, all IAM users, and require MFA via SCPs for sensitive operations
3. Minimize access: Only essential personnel should have management account credentials
4. Monitor obsessively: CloudTrail should capture every action, with alerts on suspicious activity
5. Maintain current contacts: Ensure business-managed email and phone for account recovery

Root Access Management (New 2024+)

AWS Organizations now provides centralized root access management for member accounts:

• Centrally manage root access for all member accounts from the management account or delegated administrator accounts
• Root sessions: Enable privileged root user actions on member accounts without direct root credentials
• Prevention: When enabled, prevents recovery of root user credentials in member accounts

This feature significantly improves security posture by eliminating the need for root credentials in member accounts.

Data Perimeter Strategy with SCPs and RCPs

A data perimeter ensures only trusted identities can access your data, and your data can only be accessed from expected locations. Implement using:

1. Identity perimeter (SCPs): Restrict which principals can perform actions
2. Resource perimeter (RCPs): Restrict who can access your resources
3. Network perimeter: Use VPC endpoints and PrivateLink to control network paths
4. Data classification: Tag and classify data, enforce access based on classification

Combining SCPs and RCPs creates a comprehensive perimeter that protects against both internal mistakes and external threats.

CloudTrail and Audit Configuration

Organization trails are essential for security and compliance:

• Create an organization trail that logs events from all accounts
• Store logs in a centralized Log Archive account with immutable storage (S3 Object Lock)
• Enable log file validation for tamper detection
• Configure alerts for critical events (root user activity, IAM changes, security service modifications)

For additional account security guidance, see AWS Account Best Practices and AWS Multi-Account Best Practices.

Common Security Mistakes to Avoid

Based on patterns I've seen across dozens of AWS environments:

1. Using the management account for workloads: Creates unnecessary risk and makes policy testing dangerous
2. Not enabling all policy types: Many teams only enable SCPs, missing backup policies, tag policies, and the new RCPs
3. Skipping delegated administrators: Putting all service management in the management account concentrates risk
4. No MFA on root users: Member account root users are often forgotten but still provide full account access
5. Missing CloudTrail organization trails: Per-account trails can be deleted by compromised accounts

Quotas, Limits, and Troubleshooting

Key Service Quotas to Know

Note: New organizations may start with fewer than 10 accounts. Request a quota increase early if you anticipate growth.

Common Issues and Solutions

Organization creation fails: Verify the account isn't already in an organization. Each account can only belong to one organization.

SCP not applying as expected: Trace the full OU hierarchy. A more permissive parent doesn't override a restrictive child, but you need explicit Allows at every level for an action to be permitted.

Invitation not received: Check spam folders. Invitations expire after 15 days. You can resend from the Organizations console.

Cannot remove account: Created accounts must exist for at least 7 days. The account must have a valid payment method and contacts configured for standalone operation.

Policy too large: Use the visual policy editor to minimize syntax. Remove whitespace. Consider splitting into multiple policies if you're hitting the 5,120 character limit.

Requesting Quota Increases

For account limits, request increases through Service Quotas:

1. Navigate to Service Quotas in the console
2. Select AWS Organizations (use us-east-1 region)
3. Request an increase for "Default maximum number of accounts"

Approval depends on your AWS history and use case. Provide a clear business justification for faster processing.

Conclusion and Next Steps

AWS Organizations is the foundation for any serious multi-account AWS strategy. It's free, globally available, and provides the governance capabilities you need to scale securely.

If you're just getting started:

1. Create your organization with "all features" enabled
2. Enable all policy types immediately
3. Create foundational OUs (Security, Infrastructure at minimum)
4. Set up delegated administrators for critical services
5. Follow AWS Organizations Best Practices for comprehensive configuration

If you're expanding governance:

1. Implement SCPs starting with a Policy Staging OU
2. Explore RCPs for data perimeter controls
3. Consider declarative policies for EC2/EBS/VPC enforcement
4. Enable organization-wide CloudTrail, Config, and Security Hub

If you want automation: Consider AWS Control Tower for managed guardrails, or infrastructure-as-code approaches for full customization (see Control Tower Alternatives).

The 2024-2025 additions of RCPs, declarative policies, and root access management represent a significant maturation of AWS governance capabilities. Organizations that adopt these features early will have stronger security postures and simpler compliance stories.

What aspects of AWS Organizations are you implementing or struggling with? Share your experience in the comments below.