AWS Organizations: design the organisation before the infrastructure

It is tempting to begin an AWS platform with infrastructure.

Choose a Region.

Create a VPC.

Calculate CIDR ranges.

Design subnets.

Add a Kubernetes cluster.

Provision a database.

The project appears to be moving because resources are appearing.

Then the organisational questions arrive.

Where should audit logs live?

Who may change production?

Which account should operate shared networking?

Where should protected backup copies sit?

Which system may assume roles across workload accounts?

How will a new account receive an owner, policies, logging and a retirement path?

Suddenly the network diagram is waiting on questions that should have been answered before the first route table existed.

INFRASTRUCTURE FIRST

VPC
  │
  ▼
cluster
  │
  ▼
database
  │
  ▼
workloads
  │
  ▼
now decide ownership,
authority and isolation

This ordering treats the organisation as administration surrounding the architecture.

In a multi-account AWS environment, the organisation is part of the architecture.

AWS accounts contain resources, identities, quotas, billing activity and administrative authority. AWS Organizations groups those accounts into a governed environment and applies management policies through a hierarchy. AWS recommends a multi-account approach as environments grow, including separating workloads and grouping accounts around common controls rather than reporting lines. AWS Organizations guidance

The stronger sequence is:

ORGANISATION DESIGN
        │
        ▼
ACCOUNT BOUNDARIES
        │
        ▼
IDENTITY AND POLICY
        │
        ▼
LOGGING AND SECURITY
        │
        ▼
NETWORK AND PLATFORM
        │
        ▼
WORKLOAD INFRASTRUCTURE

Design the organisation before the infrastructure because every important infrastructure decision eventually depends on ownership, isolation, authority and lifecycle.

The organisation determines where infrastructure belongs.

It determines who may change it.

It determines which policies follow it.

When something fails, it determines how far the failure can travel.

Organisation design has several views

The OU tree is important.

It is not the complete organisation architecture.

A useful design separates four maps.

ORGANISATION HIERARCHY

root
OUs
accounts
policy inheritance


ACCOUNT CONTRACTS

purpose
owner
data
authority
lifecycle


DELEGATION AND TRUST MAP

delegated administrators
cross-account roles
identity paths
automation authority


DEPENDENCY MAP

networking
DNS
logging
backups
shared services
security systems

Each answers a different question.

Organisation hierarchy

Which accounts should receive
the same organisation policies?

Account contract

Which responsibility, authority,
data and lifecycle belong here?

Delegation and trust

Which accounts and identities may operate
across other account boundaries?

Shared dependencies

Which systems can affect
several accounts simultaneously?

The OU tree is the policy-inheritance view of a wider system of account contracts, delegated authority and shared dependencies.

A neat hierarchy does not automatically create good identity, operational ownership, networking or resilience.

Those relationships need their own design.

Create accounts for meaningful boundaries

An AWS account is more than a billing container.

It can separate:

administrative authority
workloads and data
service quotas
deployment systems
security findings
cost responsibility
lifecycle
failure and compromise

AWS describes accounts as strong boundaries and recommends separating production from development and test workloads. AWS Well-Architected guidance

Suppose development and production share one account.

A development role may accidentally reach production resources.

A deployment workflow may target both environments.

One environment can consume a shared quota.

A policy experiment may disrupt customers.

Separating them changes the administrative blast radius.

ONE ACCOUNT

development
staging
production
shared tooling
      │
      ▼
shared authority and failure


SEPARATE ACCOUNTS

development │ staging │ production
      │          │          │
      ▼          ▼          ▼
bounded authority and failure

The account does not replace network, IAM or application controls.

It provides a strong wall before those finer boundaries are added.

When is another account justified?

Create a separate account when one or more of these conditions matters:

ADMINISTRATIVE AUTHORITY

different people or automation
must control it

POLICY INHERITANCE

different organisation controls
must apply

DATA OR EVIDENCE

an independent protection boundary
is required

QUOTAS

resource consumption
must be isolated

COST

a durable operating owner
needs clear attribution

LIFECYCLE

the workload can be created,
transferred or retired independently

FAILURE OR COMPROMISE

damage should be contained

An account should exist because it creates a valuable boundary, not because every platform component deserves its own name in the billing console.

This avoids both extremes:

ONE ACCOUNT FOR EVERYTHING

and:

ONE ACCOUNT FOR EVERY TOOL

Accounts should have contracts

Every account should have a small operating contract.

account:
  name: bfstore-prod
  purpose: production bfstore workloads
  state: active
  criticality: high

ownership:
  service_owner: bfstore-platform
  security_owner: bfstore-security
  ownership_verified: 2025-12-01

data:
  permitted:
    - production customer data
    - production order data
  prohibited:
    - uncontrolled test imports

authority:
  routine_deployment: production-delivery-role
  investigation: temporary-read-only-role
  emergency: incident-commander-approved

dependencies:
  - central identity
  - network account
  - log archive
  - backup account

lifecycle:
  closure_requires:
    - data disposition
    - dependency verification
    - evidence retention

The contract gives account automation something meaningful to enforce.

It also prevents the account from becoming:

the place where we put things
that looked production-shaped

Account boundaries should evolve with the estate

A small bfstore environment may begin with one production account.

Further separation may become valuable when workloads gain:

independent owners
regulated data
conflicting lifecycles
quota pressure
different deployment authority
regional or customer isolation
unacceptable shared blast radius

INITIAL

one production account


LATER

production accounts by
workload, product, Region or cell
when boundaries diverge

The first model should be understandable.

It should not be mistaken for the final scale model.

Use the hierarchy to apply tested controls

AWS Organizations contains one root, OUs and accounts. Policies attached higher in the hierarchy can affect accounts below them. AWS recommends organising OUs around common controls and workload purpose, with foundational and procedural OUs added where useful. AWS OU guidance

ROOT
│
├── Security
├── Infrastructure
├── Workloads
│   ├── NonProduction
│   └── Production
└── Lifecycle
    ├── PolicyStaging
    └── Suspended

An OU is not itself a security or isolation boundary.

It groups accounts and applies management controls.

OUs organise and apply controls to boundaries; accounts are the boundaries.

Moving an account between OUs can change its effective policies.

That makes OU placement an architectural action.

A Production OU should mean:

These accounts inherit
a deliberate production control set.

It should not mean:

These accounts look related
in the console.

Policies should follow the control model

Service control policies, or SCPs, bound the maximum permissions available to principals in member accounts.

Resource control policies, or RCPs, bound the maximum permissions that supported resources may accept.

Neither grants access.

IAM AND RESOURCE PERMISSIONS

what policies attempt to allow

SCP

maximum authority available
to principals in member accounts

RCP

maximum authority accepted
by supported member-account resources

EFFECTIVE ACCESS

the request must survive
every applicable policy layer

This is a deliberately simplified organisation-level view.

Effective access may also depend on resource policies, permissions boundaries, session policies, key policies, endpoint policies and service-specific controls.

RCP support is service-specific and can change as AWS expands the feature. Current supported services and evaluation behaviour should be checked in the AWS Organizations documentation before policy design. AWS RCP documentation

Policies need staged delivery

An organisation-wide deny can create an organisation-wide incident.

A rollout should follow:

POLICY AUTHORING
       │
       ▼
STATIC AND AUTOMATED TESTS
       │
       ▼
POLICY-STAGING ACCOUNT
       │
       ▼
TARGETED NON-PRODUCTION OU
       │
       ▼
PRODUCTION OU
       │
       ▼
BROADER ATTACHMENT

Tests should include:

expected allowed actions
expected denials
logging delivery
backup operations
delegated administration
platform automation
emergency access

AWS explicitly recommends policy-staging OUs and thorough testing before broad attachment, particularly at the organisation root. AWS OU and RCP guidance 4

The policy system deserves the same staged-delivery discipline as application code.

Exceptions need owners and expiry

Some accounts will need exceptions.

An exception should record:

affected account or OU
business reason
approving authority
compensating controls
expiry
review date

Avoid a permanent Exceptions OU that quietly becomes the least governed part of the estate.

Avoid policy topiary

Do not build an OU for every imagined future business unit, regulation or acquisition.

Start with known policy differences and lifecycle states.

Expand when a new control set genuinely appears.

A tree that looks sophisticated but cannot be reasoned about is not mature governance.

It is policy topiary.

Keep organisational authority narrow and visible

The management account should remain quiet

The account that creates the organisation becomes the management account.

It has distinctive authority over the organisation and consolidated billing.

AWS recommends restricting access, using the account only for tasks that require it, delegating responsibilities where supported and keeping workloads in member accounts. SCPs do not restrict users or roles in the management account. AWS management-account guidance

The management account should not become:

a shared-services environment
a CI runner
a network hub
a log-analysis workspace
a Terraform workstation
a home for miscellaneous resources

MANAGEMENT ACCOUNT

organisation ownership
billing responsibility
limited organisation operations
delegation configuration
protected emergency access


MEMBER ACCOUNTS

security
logging
networking
platform
workloads
backup

The management account remains the constitutional centre.

It does not need to become the operational town hall, post office, warehouse and boiler room.

The best management-account workload is usually no workload at all.

Delegate administration deliberately

Many AWS services support delegated administration from member accounts.

A delegated administrator receives service-specific authority across organisational boundaries and limited Organizations visibility. AWS recommends delegation as part of keeping routine operations outside the management account. AWS delegated-administration guidance

MANAGEMENT ACCOUNT
        │
        └── delegates service administration
                     │
          ┌──────────┼──────────┐
          │          │          │
          ▼          ▼          ▼
      security    identity    backup
       account     account     account

A delegated administrator is not a harmless secondary account.

It needs:

restricted access
strong evidence
clear ownership
tested recovery
minimal unrelated workloads

Workforce identity belongs near the beginning

IAM Identity Center can provide organisation-wide workforce access through users, groups, permission sets and account assignments. Its administration can be delegated to a member account, although the organisation instance remains associated with the management account. IAM Identity Center guidance

Responsibilities might include:

OrganisationAdministrator

SecurityOperator

NetworkOperator

PlatformEngineer

ApplicationDeveloper

ProductionInvestigator

BillingViewer

A separate network account provides useful protection only when application administrators cannot casually assume full network authority.

A log archive remains independent only when workload administrators cannot delete its evidence.

The account wall matters because identity respects it.

Root access is an organisation-level recovery concern

AWS supports centralised root-access management for member accounts. It can remove long-term member-account root credentials, create new member accounts without them and use short-term privileged sessions for supported root-level tasks from the management account or an IAM delegated administrator. Some root tasks still require recovering root credentials and signing in as the member-account root user. AWS root-access guidance

The design should specify:

how the management-account root is protected
who controls account recovery channels
whether member root credentials exist
how privileged sessions are authorised
how root activity is detected
how exceptional credential recovery is tested

A root credential stored in one person’s password manager is not an organisational recovery model.

Automation authority is high-impact authority

Shared delivery systems may assume roles across several accounts.

PLATFORM CONTROL PLANE
          │
          ├── development role
          ├── staging role
          └── production role

Production authority should not merely be the development role with a more exciting profile name.

The trust map should record:

which runner can assume each role
which repository and revision can trigger it
which state it can access
which environment it can modify
which evidence it must produce

Separate the services that protect and operate the estate

Some accounts exist because their responsibilities should survive or remain independent from workload compromise.

AWS reference architectures commonly use dedicated Security Tooling and Log Archive accounts and separate infrastructure capabilities such as networking and shared services. These are reference patterns, not a requirement to create one account for every named tool. AWS Security Reference Architecture

Logging and security

Audit evidence should leave the workload account.

A central bucket is not automatically a trustworthy archive.

The design should answer:

who may write
who may read
who may alter retention
whether workload administrators can delete copies
how delivery failure is detected

A compromised production workload should not automatically compromise the control plane used to investigate it.

Backup

A separate backup account can protect copies and recovery administration from ordinary workload authority.

The design should still ask whether backup and production share:

organisation administrators
identity provider
encryption authority
Region
central automation

A separate account reduces some failure paths.

It does not create absolute independence.

Networking

A network account may own:

IP address management
shared routing
DNS authority
egress policy
connectivity services

Centralised management does not always require a centralised data path.

CENTRALISED MANAGEMENT

does not always require

CENTRALISED TRAFFIC

The account boundary protects network administration without requiring every packet to visit one majestic appliance.

Shared platform services

Backstage, Crossplane and infrastructure automation may be centralised.

Their failure and compromise modes should be explicit.

Backstage unavailable:
    discovery degraded
    workloads continue

Crossplane unavailable:
    new fulfilment blocked
    existing resources continue

automation compromised:
    cross-account change authority at risk

Shared services should not become unexplained shared fate.

Operate accounts through a governed lifecycle

The account is a platform product.

It should move through explicit states.

REQUESTED
    │
    ▼
ONBOARDING
    │
    ▼
BASELINE VERIFIED
    │
    ▼
ACTIVE
    │
    ▼
TRANSITIONING
    │
    ├── quarantine
    ├── ownership transfer
    └── policy migration
    │
    ▼
SUSPENDED
    │
    ▼
CLOSED

Request and onboarding

The request should provide:

purpose
owner
environment
data classification
cost centre
required connectivity
expected lifetime

Automation can then create the account, place it in a staging OU and apply its baseline.

Baseline verification

The workflow should verify outcomes rather than merely report that automation completed.

Useful evidence includes:

expected policy attachments
logging delivery
security-service enrolment
Identity Center assignments
budgets and contacts
backup registration
ownership metadata
prohibited public exposure
recovery dependencies

Only a conformant account should move into its target OU.

Active operation

Ownership, contacts, runbooks and recovery evidence should have freshness dates.

A populated field is not necessarily a trustworthy field.

Transition and quarantine

An account may need:

temporary containment
ownership transfer
policy migration
incident quarantine
data relocation

Each state should define allowed activity, access and exit conditions.

Closure

An account is not immortal because its original project ended quietly.

Closure requires:

dependency checks
data disposition
backup decisions
access removal
evidence retention
billing review
traceable approval

Cost is another form of blast radius.

The account identifies the operating boundary that created the cost.

Tags identify services and components within it.

The bfstore organisation

A first bfstore hierarchy could be:

Root
│
├── Security
│   ├── bfstore-security-tooling
│   └── bfstore-log-archive
│
├── Infrastructure
│   ├── bfstore-network
│   ├── bfstore-identity
│   ├── bfstore-platform
│   ├── bfstore-observability
│   └── bfstore-backup
│
├── Workloads
│   ├── NonProduction
│   │   ├── bfstore-dev
│   │   └── bfstore-staging
│   └── Production
│       └── bfstore-prod
│
└── Lifecycle
    ├── PolicyStaging
    │   └── bfstore-policy-test
    └── Suspended

This is a starting model, not a universal account count.

The Infrastructure accounts may later need different child OUs or directly attached policies when their controls diverge.

The hierarchy is only one view.

The account contract explains purpose.

The trust map explains cross-account authority.

The dependency map reveals shared fate.

Once those views exist, infrastructure placement becomes easier.

production VPC:
    bfstore-prod

IPAM and shared routing:
    bfstore-network

audit archive:
    bfstore-log-archive

platform control plane:
    bfstore-platform

protected recovery copies:
    bfstore-backup

The organisation gives every resource a home before the resource exists.

Questions I now ask

Boundary

Which authority, failure, data
or lifecycle requires this account?

Contract

Which purpose, owner
and permitted use define it?

Inheritance

Which OU policies
should the account receive?

Trust

Which delegated administrators
and automation identities may cross it?

Evidence

Which logs, backups and recovery paths
leave the account?

Dependencies

Which shared systems reconnect
its failure boundary?

Conformance

How is the baseline verified,
and how do exceptions expire?

Lifecycle

How is the account transferred,
quarantined, suspended and closed?

These questions turn account creation into architecture rather than registration.

The mental model I am keeping

My earlier model was:

AWS Organizations

a billing feature
with folders for accounts

The stronger model is:

                     BUSINESS AND SERVICE NEEDS
                                │
                                ▼
                       ACCOUNT BOUNDARIES
                                │
              ┌─────────────────┼─────────────────┐
              │                 │                 │
              ▼                 ▼                 ▼
          HIERARCHY          CONTRACTS       TRUST MAP
              │                 │                 │
              └─────────────────┼─────────────────┘
                                ▼
                       SHARED DEPENDENCIES
                                │
                                ▼
                  POLICY, IDENTITY AND EVIDENCE
                                │
                                ▼
                     GOVERNED ACCOUNT LIFECYCLE
                                │
                                ▼
                       CLOUD INFRASTRUCTURE
                                │
                                ▼
                         RUNNING SERVICES

The hierarchy answers:

Which accounts share controls?

The account contract answers:

Which purpose, authority,
data and lifecycle belong here?

The trust map answers:

Who may operate
across account boundaries?

The dependency map answers:

Which shared systems
can still create common failure?

The lifecycle answers:

How is the boundary created,
verified, changed and retired?

Infrastructure is easier to design once these answers exist.

The VPC has an owner.

The cluster has an administrative boundary.

The database has a data environment.

The deployment system has a defined trust path.

The logs have somewhere safer to go.

The backup has somewhere separate to survive.

AWS Organizations is not packaging applied after the platform has been built. It is the skeleton that determines where the platform’s organs belong, which nerves may reach them and how far damage can spread.

Designing the organisation first does not delay infrastructure.

It prevents infrastructure from quietly making organisational decisions on our behalf.

The first VPC can wait.

Its account, authority, evidence and recovery path should not.