Organizations, Accounts, OUs and Policies

An AWS organization contains two kinds of account.

• The management account (also called the payer account) creates the organization, receives the consolidated bill, and is the only account that can create or invite member accounts and attach policies. It is deliberately kept empty of workloads.
• Member accounts are every other account in the organization. The usual split is by environment and by team ownership, so that a blast radius is an account boundary rather than a naming convention.

Policies are authored in the management account and attached to an OU; every account in that OU inherits them.

Billing

• Consolidated billing rolls every member account’s charges up to the management account, so there is one payment method and one invoice. Cost Explorer and Cost and Usage Reports can then break that single bill back down by account, service or tag.
• Volume discounts apply to the aggregated usage rather than to each account separately. Tiered services (S3 storage is the clearest example) charge the cheaper tier rate once the organization’s combined volume crosses the tier boundary, which no single account would have reached on its own.
• Reserved Instances and Savings Plans bought in one account are applied across the organization by default, so a commitment does not have to be tied to the account that made it.

Organizational units

An organizational unit (OU) is a logical grouping of accounts inside the organization. OUs can nest. Policies attach to the root, to an OU, or to an individual account, and are inherited downwards — an account gets only what every level above it permits.

Policy types

AWS Organizations offers two broad families of policy.

Authorization policies

These set the maximum permissions available. They never grant anything: permissions still have to come from IAM identity-based and resource-based policies, and the effective permission is the intersection.

	Service control policies (SCPs)	Resource control policies (RCPs)
Bounds the permissions of	IAM users and roles in the account	Resources in the account
Affects the management account	No	No
Affects a member account’s root user	Yes	Yes
Maximum attached per root, OU or account	10	5

Two consequences are worth stating plainly, because they are frequently got wrong:

• SCPs do not apply to the management account. Nothing an SCP says restricts a user or role there, which is the main reason not to run workloads in it. Anyone with administrator rights in the management account can do what the organization’s policies forbid everywhere else.
• SCPs do apply to a member account’s root user. They are the standard way to stop a member account’s root user from doing something, subject to a short list of exceptions AWS documents — registering for a support plan as root, service-linked roles, and a handful of legacy services. Centralised root access management in IAM is the complementary control: it lets the management account remove root credentials from member accounts entirely.

RCPs are the other half of the picture. An SCP cannot stop a principal from outside the organization reaching a resource inside it, because SCPs only bound principals the organization manages. An RCP bounds the resource, so it holds regardless of who is calling.

Declarative policies

Declarative policies centrally configure a service and keep that configuration in place as the service gains new features and APIs. Unlike SCPs and RCPs, they do apply to the management account. The current set covers Amazon EC2, backup plans, tags, chat applications, AI services opt-out, Security Hub, Amazon Inspector, Amazon Bedrock, upgrade rollout and Amazon S3. Tag policies are the one most teams meet first: they standardise the tag keys and values allowed on resources across every account, which is what makes cost allocation by tag trustworthy.

Account practices

• Create a dedicated logging account and send the organization trail’s CloudTrail logs there. No workload account should be able to delete its own audit record.
• Reach member accounts with cross-account roles rather than an IAM user per account.
• More than one account per application is normal — separating production from non-production is usually the first split, and a separate account for shared services follows.
• If you are building this from scratch rather than inheriting it, look at AWS Control Tower first. It stands up the organization, the logging and audit accounts, and a baseline set of controls in one pass.