AWS Organizations Best Practices: Structure, Policies, and Governance

AWS Organizations is the infrastructure layer for enterprise-grade multi-account AWS management. Without Organizations, managing a portfolio of AWS accounts is a collection of independent tasks: separate billing, separate security configurations, no guardrails preventing accounts from drifting from your standards. With Organizations, you have centralized billing, policy enforcement that applies to all accounts simultaneously, and the ability to provision new accounts programmatically with your standard baseline applied automatically.

The design decisions you make when setting up Organizations — how you structure Organizational Units, how broadly you apply Service Control Policies, where you put specific workloads — determine how manageable the environment is as it grows. Getting these decisions right from the beginning is worth the investment.

Organization Structure Foundations

An AWS Organization consists of a management account (formerly called the master account) and member accounts, organized into Organizational Units (OUs). The management account should do one thing: manage the organization. Run no production workloads in the management account. Give it the most restrictive access policies of any account in the organization. Reserve it for billing, account management, and organization-level configuration.

Create dedicated accounts for specific shared functions: a Log Archive account that receives CloudTrail logs from all other accounts (with policies preventing log deletion), an Audit/Security Tooling account that runs GuardDuty and Config aggregators across the organization, a Shared Services account for infrastructure used across multiple teams (DNS, artifact repositories, transit gateways), and a Network account if you're using complex VPC sharing or Transit Gateway topologies.

These foundational accounts are part of every serious multi-account AWS reference architecture (AWS's own Landing Zone Reference Architecture and Control Tower implement them by default). Don't skip them in the name of simplicity — they become essential as the organization grows.

Organizational Unit Design

OUs provide the hierarchy for applying Service Control Policies to groups of accounts. Common OU structures:

By lifecycle stage: Foundational (Log Archive, Audit), Infrastructure (Shared Services, Network), Workloads/Production, Workloads/Development, Workloads/Staging, Sandbox. This structure reflects the standard AWS Landing Zone pattern and makes it easy to apply different SCPs to production accounts (stricter) versus sandbox accounts (more permissive).

By business unit: Engineering, Finance, Marketing, each with their own OU subtree. Useful for organizations with very different AWS usage patterns across business units where BU-specific SCPs are needed. More complex to manage as the BU count grows.

By regulatory requirement: Accounts handling PCI data in a PCI OU with enhanced SCPs, HIPAA accounts in a HIPAA OU, standard accounts in a general OU. Clean compliance boundary separation.

In practice, a hybrid works best: a lifecycle-based top-level structure (Production, Non-Production, Sandbox) with sub-OUs for regulated workloads that need specific policy treatment. This prevents an explosion of OUs while maintaining the governance boundaries that matter.

Account Vending and Baseline Automation

Manual account creation doesn't scale. Each new account needs the same baseline: CloudTrail enabled, Config enabled, GuardDuty enrolled, access roles provisioned, tagging policies enforced. Without automation, these steps are performed inconsistently and some are missed.

AWS Control Tower (covered in detail in the Control Tower guide) provides an account factory that automates baseline application. For organizations that prefer Terraform-based automation, the AWS Organizations API combined with a post-creation CloudFormation StackSet deployment achieves the same result.

Regardless of tooling, the baseline should be defined as code, applied automatically on account creation, and checked continuously with AWS Config rules that alert when the baseline drifts. An account that had CloudTrail enabled at creation but had it disabled three months later by someone "temporarily" is a gap in your audit posture.

Consolidated Billing Configuration

Consolidated billing in Organizations aggregates charges from all member accounts to the management account. This provides several practical benefits: Reserved Instance and Savings Plan discounts apply across all accounts, you see a single itemized bill for the entire organization, and Cost Explorer can display costs across all accounts in one view.

Configure cost allocation tags at the organization level so that tags used for cost attribution are recognized across all member accounts. Without this configuration, tags used for cost allocation in member accounts may not appear in consolidated billing reports. Enable cost allocation tags in Billing Console → Cost Allocation Tags, and add all tags used across your organization for cost attribution (Environment, Application, Team, etc.).

Service Control Policy Strategy

SCPs are covered in depth in the Service Control Policies guide. From an organization design perspective, the key principles are:

Attach SCPs at the OU level, not the account level, wherever possible. Account-level SCP attachment creates complexity — it becomes hard to reason about what applies to an account when some policies come from the OU hierarchy and others from account-level attachment. Reserve account-level SCPs for exceptions that apply to a specific account but not its siblings in the same OU.

Maintain a small set of core SCPs that apply to all OUs (deny all actions in prohibited regions, deny disabling CloudTrail, deny leaving the organization, deny changing Organization settings). These are your non-negotiable guardrails. Additional SCPs in specific OUs add constraints appropriate to that OU's workloads.

Related Reading

• Service Control Policies guide — implementing guardrails in your Organizations structure
• AWS Control Tower setup — automated account vending and baseline management
• Organizational Unit structure — detailed OU design patterns
• Multi-account monitoring — monitoring across an Organizations hierarchy

FAQ

Should the management account have production workloads?

No. The management account has elevated permissions that can affect all member accounts — it can apply SCPs, create and delete accounts, and has access to consolidated billing data. If a workload in the management account is compromised, the blast radius extends to your entire AWS organization. Keep the management account empty of workloads and restrict human access to it to organization administrators only.

How many accounts is too many?

AWS supports up to 10,000 accounts in an organization by default (increasable via support case). Most organizations should have more accounts than they think they need — the "one account per environment per service" pattern (Production, Staging, Development each getting separate accounts for each major service) results in many accounts but provides strong isolation between environments. Accounts are free to create; the complexity of managing many accounts is the actual constraint, and Organizations tooling makes that manageable at scale.

Can I move accounts between OUs without disruption?

Yes. Moving an account between OUs in the Organizations console changes which SCPs apply to it immediately. There's no account downtime or resource disruption — the IAM evaluation changes take effect immediately. Be careful when moving accounts to more restrictive OUs that the SCPs in the target OU won't deny API calls that the account's workloads depend on. Test in non-production first and monitor for permission-denied errors after moving.