AWS Account Structure: Organizations, OUs and Multi-Account Design

Why one AWS account stops being enough

Most people meet AWS through a single account. You sign in, launch an EC2 instance, create an S3 bucket, and everything lives in one place. That works for a weekend project. It stops working the moment a second team, a second environment or a second billing owner shows up.

The reason is that an AWS account is the hardest boundary the platform offers. IAM policies, service quotas, CloudTrail logs, billing and even the blast radius of a leaked credential all stop at the account edge. AWS itself recommends running multiple accounts and stitching them together with AWS Organizations rather than cramming everything into one.

This guide walks through the vocabulary of Organizations, a reference layout you can adapt, what service control policies really do, and the tooling that makes a multi-account estate manageable. If you are still deciding whether the AWS model or a competitor suits you, the AWS versus Azure comparison covers how each vendor draws these boundaries.

The vocabulary: root, OUs, management and member accounts

AWS Organizations is a free service that lets you group accounts into a tree. Every organization has exactly one management account. This is the account that created the organization, pays the consolidated bill, and holds the keys to policy. Treat it as sensitive infrastructure: run nothing in it except organization administration.

Every other account is a member account. Member accounts are either created from inside Organizations (which is the tidy path) or invited in from outside. The top of the tree is the root, and beneath it sit organizational units, usually shortened to OUs. An OU is simply a container for accounts and other OUs, and policies attached to an OU flow down to everything inside it.

Two feature sets exist. Consolidated billing only pools invoices and volume tiers but nothing else. All features unlocks policies, delegated administration and integration with other services. Almost every new organization should enable all features from day one, because switching later requires each member account to approve the change.

A reference OU layout you can adapt

AWS publishes guidance on organizing accounts, and the pattern that emerges from it is remarkably stable across companies of very different sizes. The table below is a condensed version. You will not need every OU on the first day, but naming them early avoids painful moves later.

Notice what is not in the table: a single "Dev" OU holding every team's development work. Environments are better expressed as separate accounts inside a per-workload OU than as one giant shared account. Separating production from non-production this way is also how you keep the staging environment honest, since it gets its own quotas, its own IAM and its own bill.

Service control policies and what they cannot do

A service control policy (SCP) is a JSON document, written in the same grammar as IAM, that sets the maximum permissions available in an account. SCPs never grant anything. They only carve away. If an SCP on the Workloads OU denies ec2:RunInstances outside two approved regions, no IAM user or role in any account under that OU can launch elsewhere, even an administrator.

That last point is the whole value. SCPs apply to the account root user and to every principal in the account, which makes them the only mechanism that constrains someone who already has full IAM rights. Common guardrails include denying regions you do not operate in, protecting the CloudTrail configuration, blocking account-leaving actions and requiring that new S3 buckets are not made public.

Organizations also supports resource control policies (RCPs), which take the same idea and apply it from the resource side, for example restricting which principals may call an S3 bucket in your organization. Tag policies, backup policies and declarative policies round out the set, each addressing a narrower governance concern.

What SCPs cannot do is manage the management account itself, which is exempt, or replace IAM. Someone still has to grant permissions inside each account. The broader model of users, roles and least privilege is covered in Cloud IAM Fundamentals.

Control Tower, IAM Identity Center and consolidated billing

AWS Control Tower

Control Tower sits on top of Organizations and automates the reference layout. It provisions a landing zone with the Security OU and its two accounts, applies a set of preventive and detective controls, and offers an Account Factory for creating new member accounts that arrive pre-wired with logging and baseline networking. Teams that would otherwise script all of this in CloudFormation often find Control Tower a faster starting point.

IAM Identity Center

With many accounts, per-account IAM users become unmanageable. IAM Identity Center (formerly AWS SSO) gives people one login, mapped through permission sets to roles in whichever accounts they need. It connects to an external identity provider or uses its own directory. Enabling it in the management account and delegating administration to a member account is a common pattern.

Consolidated billing

The management account receives one invoice that aggregates every member account. Usage is pooled for volume-tiered services, and Reserved Instance and Savings Plans discounts can be shared across accounts unless you switch that sharing off. Cost Explorer and AWS Budgets can filter by linked account, which pairs well with the budget alert habits described elsewhere in the journal.

Organization-wide logging deserves a mention too. An organization trail in CloudTrail captures API activity from every member account into the Log Archive bucket automatically, including accounts created later, so audit coverage never lags behind growth.

Doing it from the CLI

Everything in the console is also available through the organizations namespace of the AWS CLI, which is handy when you want the layout captured in a script or in Terraform. A minimal bootstrap from the management account looks like this.

• aws organizations create-organization --feature-set ALL turns the current account into a management account with all features enabled.
• aws organizations list-roots returns the root ID you need as a parent for top-level OUs.
• aws organizations create-organizational-unit --parent-id r-abcd --name Workloads creates an OU beneath the root.
• aws organizations create-account --email prod@example.com --account-name Prod starts asynchronous account creation; poll it with describe-create-account-status.
• aws organizations move-account --account-id 111122223333 --source-parent-id r-abcd --destination-parent-id ou-abcd-11111111 files the new account under the right OU.
• aws organizations attach-policy --policy-id p-xxxxxxxx --target-id ou-abcd-11111111 binds an SCP to that OU.

Each account created this way contains an OrganizationAccountAccessRole that the management account can assume, which is how automation reaches into fresh accounts before any other IAM exists. The official AWS Organizations user guide documents every parameter and the trust relationship of that role.

Mistakes that are expensive to undo

Running workloads in the management account. It is exempt from SCPs and it controls billing for everyone. Anything deployed there is unguarded, and moving it out later means a migration.

Using the root user for daily work. Every account has a root user with an email address and password. Lock it with MFA, store the credentials offline, and do everything else through Identity Center roles. The MFA guide covers the mechanics.

Reusing one email address. Each account needs a unique root email. Plus-addressing (aws+prod@example.com) or a dedicated distribution list per account keeps recovery messages routable.

Skipping tagging standards. Cost allocation tags only help if they are applied consistently from the start. A tag policy at the root enforces case and allowed values before drift sets in.

If you are starting with an AWS account supplied through AllCloudShop, the same principles apply: decide early whether it becomes a standalone account or a member of an organization you already run, and configure it accordingly under the provider's terms. The AWS account listing describes the variants available.

Key takeaways

• An AWS account is the strongest isolation boundary on the platform; use several of them, joined by AWS Organizations with all features enabled.
• Keep the management account empty of workloads and reserve it for billing, policy and identity administration.
• Adopt the Security, Infrastructure, Workloads, Sandbox and Suspended OU pattern, then nest per-product OUs as you grow.
• SCPs set ceilings, never grants; test them in a staging OU because they override administrators.
• Use Control Tower to automate the landing zone, IAM Identity Center for human access, and an organization trail for audit coverage.
• Script the structure with the aws organizations commands so it is reproducible and reviewable.