AWS Organizations

AWS Organizations lets you centrally manage and govern multiple AWS accounts. It is the foundation for multi-account security architecture.

Key Features

• Organizational Units (OUs): hierarchical grouping of accounts (for example Production, Development, Security, Sandbox)
• Service Control Policies (SCPs): organization-wide permission guardrails that restrict what member accounts can do
• Resource Control Policies (RCPs): guardrails applied to resources rather than principals
• Consolidated Billing: single payment method for all accounts with volume discounts
• Delegated Administrator: designate member accounts to manage specific services (Security Hub, GuardDuty, Macie)
• Tag Policies: enforce consistent tagging across all accounts
• AI Services Opt-out Policies: control whether AWS AI services can store your data for improvement

Multi-Account Strategy

• Management Account: only for Organizations management, not workloads
• Security Account: centralized security services (GuardDuty, Security Hub, log archive)
• Log Archive Account: centralized, immutable logging (CloudTrail, Config)
• Network Account: shared networking (Transit Gateway, VPN, Direct Connect)
• Workload Accounts: separate accounts per environment or application

Quotas That Shape Your Design

These numbers matter when you plan an org structure, because several are hard limits:

• An organization has exactly one root and can contain up to 2000 OUs
• OUs can nest five levels deep under the root
• The default maximum number of accounts is 10, adjustable through Service Quotas; increases can go up to 50,000 accounts depending on the customer
• You can attach at most 10 SCPs to the root, to any single OU, and to any single account. Policies inherited from a parent do not count against that limit, and all policy attachment limits are hard limits
• Every entity must have at least one SCP attached when SCPs are enabled; you cannot remove the last one
• An SCP document is limited to 10,240 characters; an RCP to 5120 characters. Whitespace is stripped when you save from the console but preserved when you save through the CLI or an SDK, which can make an identical policy fail from CI and succeed from the console
• At most 5 RCPs can be attached to the root, an OU, or an account, and the RCPFullAWSAccess policy counts against that five

How It Goes Wrong in Practice

The most damaging Organizations mistake is running workloads in the management account. SCPs do not apply to the management account, so every guardrail you build for the rest of the organization is absent exactly where the organization's own control plane lives. A compromise of any principal in the management account is a compromise of the entire org: the attacker can detach SCPs, create accounts, or invite accounts. Keep the management account empty of workloads, restrict who can access it, and use delegated administrators so that security teams operate from a member account instead.

The second pattern is the SCP character limit turning into an outage. Teams start with a small region-restriction policy, then keep appending exception ARNs as edge cases appear. At 10,240 characters the update fails, someone splits the policy in two, and now the OU has multiple SCPs whose intersection is stricter than anyone intended, because SCPs at different levels all have to allow an action for it to be permitted. Deployments start failing in ways that are hard to trace, since an SCP denial surfaces as a plain AccessDenied without naming the policy.

Third, teams forget that moving an account between OUs instantly changes its effective permissions. Dragging a production account into a stricter OU during a reorganization can break running automation in seconds, with no staged rollout and no dry run. Test SCP changes against a sandbox OU first, and use aws iam simulate-principal-policy or CloudTrail review before moving accounts.

Listing Policies From the CLI

To see every SCP in the organization:

aws organizations list-policies --filter SERVICE_CONTROL_POLICY

--filter is required. Valid values include SERVICE_CONTROL_POLICY, RESOURCE_CONTROL_POLICY, TAG_POLICY, BACKUP_POLICY, AISERVICES_OPT_OUT_POLICY, DECLARATIVE_POLICY_EC2, SECURITYHUB_POLICY, and several others. Each returned policy has an Id, Arn, Name, Description, Type, and an AwsManaged flag. Follow up with aws organizations list-targets-for-policy --policy-id p-examplepolicyid to see what each policy is attached to. Note that Organizations is a global service hosted in us-east-1, so quota operations and some API calls must target that Region.

Frequently Asked Questions

Do SCPs apply to the management account?

No. SCPs never restrict the management account, including its root user. That is the primary reason to keep workloads and human access out of it. In member accounts, SCPs do apply to everyone, including the root user. Two exceptions are worth remembering: SCPs do not restrict actions performed with the permissions attached to a service-linked role, and disabling the SCP policy type in a root detaches every SCP and does not restore the attachments if you re-enable it.

How many accounts should I have?

There is no universal number, but the default quota of 10 is a starting point that most organizations outgrow. Plan around isolation boundaries rather than headcount: separate accounts per environment per workload is a common baseline, plus dedicated security, log archive, and network accounts. Request the quota increase early, since the management account is the only one that can submit it.

What is the difference between an SCP and a resource control policy?

An SCP caps what principals in your accounts can do. An RCP caps what can be done to resources in your accounts, including by principals outside your organization. They are complementary: SCPs address your identities, RCPs address access to your data.