beginnerintermediateadvanced

AWS · Accounts and Organizations

Accounts and Organizations

Why account boundaries matter, and the small set of accounts a mature setup actually creates

Accounts are a hard boundaryIAM, quotas, and blast radius all stop at the edge
SCPs are a ceilingthey only remove permissions, never grant any
Cross-account = assumed roletemporary credentials, nothing long-lived copied over
Vend, don't hand-buildguardrails attached automatically at account creation

1.Why production should not live in one undifferentiated account

An AWS account is a hard boundary — IAM permissions, resource limits, even a compromised credential all stop at the account edge. Putting development, staging and production in one account means a mistake in one can reach the others.

Key features

An account is a real security boundary, not just a folder
A leaked credential in dev cannot reach a separate prod account
Service quotas are per-account — one workload cannot starve another
The bill is also per-account, making cost attribution exact
Splitting later means migrating live resources, not just relabeling

What actually changes when you split accounts

One account for everything

A dev IAM policy typo can touch a prod resource
Runaway test traffic competes with prod for the same quotas
One compromised credential is a blast radius over everything
The bill is one number — cost by environment needs tagging discipline

One account per environment

IAM policies in dev cannot reach prod resources at all
Each environment has its own service quotas
A compromised dev credential stops at the dev account boundary
The bill is naturally split per environment, no tagging required

Command

text

One account, three environments        Three accounts, one per environment
─────────────────────────────           ─────────────────────────────
dev + staging + prod resources    →     111111111111  dev
share IAM, quotas, blast radius         222222222222  staging
                                         333333333333  prod

An account is a real security boundary. Separating dev/staging/prod by account, not by naming convention, stops a mistake in one reaching another.

2.AWS Organizations, OUs, and service control policies

AWS Organizations groups accounts under one management account: it bills them together, folds accounts into organizational units (OUs), and can attach a service control policy (SCP) to cap what every account in an OU may do.

Organizations vocabulary

Organizations vocabulary
Term	What it is
Management account	The account that created the organization; owns billing and can attach SCPs
Member account	Any other account joined to the organization
Organizational unit (OU)	A folder-like grouping of accounts, can be nested
Consolidated billing	One invoice across every member account, often at better volume pricing
Service control policy (SCP)	A permission ceiling attached to an account or OU
Account-level isolation	Each account still has its own IAM, resources, and quotas

Command

text

aws organizations create-organization
aws organizations create-organizational-unit --parent-id <root-id> --name Prod
aws organizations create-account --email prod@company.com --account-name payments-prod
aws organizations attach-policy --policy-id <scp-id> --target-id <ou-id>

An SCP is a ceiling, never a grant — it can only take permissions away from what IAM in the account would otherwise allow, never add any.

3.Environment separation: dev, staging, prod, security, shared services

A mature AWS setup is a small, deliberate account set: one per lifecycle stage (dev, staging, prod), one dedicated to security/logging that nothing else can write to, and one shared-services account for things every other account needs.

Key features

Dev, staging and prod are each their own account, not a tag
A security/logging account should be write-only from every other account
Shared-services holds things every account needs, like a container registry
Fewer, well-defined accounts beat one account per team or per developer
The pattern scales by adding OUs, not by renaming existing accounts

A minimal, deliberate account layout

security-log-archive

write-only from every other account

shared-services

registry, shared tooling, shared VPC endpoints

payments-dev

widest access, least trust

payments-staging

mirrors prod configuration

payments-prod

narrowest access, most trust

Command

text

security-log-archive     ← every account ships CloudTrail/logs here, write-only
shared-services          ← container registry, shared VPC endpoints, tooling
payments-dev
payments-staging
payments-prod            ← smallest IAM footprint, most restricted

Separate by lifecycle stage and trust level — dev/staging/prod, plus write-only logging and shared-services — not by team or naming convention.

4.Cross-account IAM roles

A cross-account role lives in one account and its trust policy names exactly which other account may assume it. A user or automation there can temporarily become the role — no long-lived credential ever crosses accounts.

Command

text

# in the target account (prod), the role's trust policy:
{
  "Principal": { "AWS": "arn:aws:iam::222222222222:root" },  # the source account
  "Action": "sts:AssumeRole"
}

# from the source account (222222222222):
aws sts assume-role \
  --role-arn arn:aws:iam::333333333333:role/DeployRole \
  --role-session-name deploy-2026-08-20

Assuming a role issues short-lived, temporary credentials — nothing long-lived ever needs to be copied or stored across the account boundary.

5.Account vending, guardrails, and organization-wide governance

Account vending stands up a new account through an automated process — SCPs, logging, and baseline IAM roles already attached — instead of clicking through creation by hand. Guardrails keep every vended account in policy automatically.

Command

text

New account request
      ↓
Account vending (automated): create account, join Organization,
  attach baseline SCPs, enable CloudTrail → security-log-archive,
  create baseline IAM roles
      ↓
Guardrails stay active: preventive (SCP blocks a disallowed action),
  detective (AWS Config flags a drift from policy)

A guardrail is preventive (an SCP blocks it) or detective (Config/CloudTrail flag it after) — a mature setup uses both, not one instead of the other.

Spotted a mistake on this page? Tell us.

Read Sheet