A team creates one AWS account.
Inside it, they build:
- a development VPC
- a staging VPC
- a production VPC
- several Kubernetes clusters
- shared databases
- CI/CD roles
- logging
- backup storage
Every resource has a careful name.
bfstore-dev-vpc
bfstore-staging-vpc
bfstore-prod-vpc
The names create the appearance of separation.
The environments may even use different subnets, security groups and Kubernetes namespaces.
Then an administrator receives:
AdministratorAccess
The role can change all three environments.
A development workflow can potentially assume production authority.
A destructive infrastructure command can target resources across the account.
A service quota exhausted by one environment can affect the others.
The resources have different names.
They remain inside one administrative boundary.
ONE AWS ACCOUNT
│
├── development
├── staging
├── production
├── shared tooling
└── shared authority
Moving the environments into separate accounts changes the architecture.
bfstore-dev
│
└── development authority and resources
bfstore-staging
│
└── staging authority and resources
bfstore-prod
│
└── production authority and resources
Access between them must be created deliberately.
Policies can differ.
Applicable account-scoped quotas are separated.
Costs become clearer.
A failure in one account has fewer automatic paths into the others.
An AWS account is a strong but permeable architectural boundary around authority, resources, data, quotas, cost, change and operational consequence.
It is strong because these concerns meet inside one administrative context.
It is permeable because useful systems still need selected cross-account relationships.
The value of the boundary therefore depends on two decisions:
WHAT BELONGS INSIDE?
and:
WHICH PATHS MAY CROSS?
What an account boundary contains
An account is not a folder.
A folder organises things.
An account changes their administrative context.
Resources inside an account share relationships with:
- IAM roles and policies
- account settings
- service quotas
- billing activity
- API history
- organisation policies
- regional service configuration
- deployment authority
Resources in separate accounts do not gain implicit administrative access merely because the accounts belong to the same AWS organisation.
Cross-account access must be created deliberately through supported trust, policy, networking or service-integration mechanisms.
Naming remains useful.
It should describe architecture rather than impersonate it.
Administrative boundary
The account contains authority.
Roles, policies, service-linked roles and account-specific trust relationships determine how identities may act inside it.
A cross-account role creates two distinct decisions.
TRUST POLICY
Who may become this role?
PERMISSION POLICY
What may the role do?
Suppose deployment automation runs in bfstore-shared-services.
A weak design grants one broad path to every environment.
shared deployment identity
│
├── development
├── staging
└── production
A stronger design uses separate trust relationships.
development runner
│
▼
bfstore-dev deployment role
production runner
│
▼
bfstore-prod deployment role
The production path may require:
- a protected repository environment
- an approved workflow
- narrower permissions
- shorter sessions
- stronger evidence
- explicit release conditions
The account gives least privilege a larger structural boundary on which to stand.
Resource boundary
The account contains resources and many applicable quota limits.
A workload may:
- create excessive resources
- exhaust an API or service quota
- change shared configuration
- delete infrastructure
- generate unexpected cost
If unrelated workloads share one account, those failure paths overlap.
SHARED ACCOUNT
│
├── catalog
├── payments
├── analytics
└── experimentation
Account separation can isolate some forms of competition.
ACCOUNT-REGIONAL QUOTA
applies within an account
and Region
ACCOUNT-GLOBAL QUOTA
applies within an account
WIDER SERVICE OR PROVIDER LIMIT
may still affect several accounts
Accounts do not reserve provider capacity or eliminate organisation-wide dependencies.
They prevent unrelated workloads from competing inside the same applicable account boundary.
A quota is not administrative trivia.
It is a capacity boundary with an error message.
Information boundary
The account contains data, evidence and recovery inputs.
Production customer data should not drift casually into:
- sandbox
- policy testing
- developer experiments
- shared tooling
- observability test environments
A production account may state:
PERMITTED
production customer data
production order data
production operational state
PROHIBITED
uncontrolled test imports
personal developer datasets
unrelated application data
Data can cross the account boundary.
Backups may move to a protected account.
Logs may move to an archive.
Applications may retrieve approved shared assets.
Those transfers should be explicit architectural relationships.
Operating boundary
The account is also a durable unit of:
- ownership
- cost attribution
- budgets
- support
- recovery
- lifecycle
Within consolidated billing, an account provides a clear financial partition.
ACCOUNT
which operating boundary
created the cost?
TAG
which service or component
created it inside the boundary?
Cost is another form of blast radius.
The account also needs an owner from creation to closure.
A boundary without lifecycle ownership becomes a permanent administrative fossil.
Use an account-boundary contract
Every important account should have a compact contract describing what the boundary protects and how it is allowed to interact with the rest of the platform.
account:
name: bfstore-prod
purpose: production bfstore workloads
state: active
criticality: high
protected_consequence:
- customer orders
- production availability
- production data
permitted_workloads:
- catalog
- basket
- order
- payment
- review
administrative_authority:
deployment: production-delivery-role
investigation: temporary-read-only-role
emergency: incident-commander-approved
permitted_data:
- production customer data
- production order data
inbound_trust:
- approved production runner
- workforce investigation role
outbound_dependencies:
- bfstore-network
- bfstore-log-archive
- bfstore-backup
- central identity
quota_owner:
bfstore-platform
recovery:
protected_copy: bfstore-backup
last_restore_demonstrated: 2025-12-10
evidence:
logging_last_verified: 2025-12-15
trust_last_reviewed: 2025-12-01
owner_last_verified: 2025-12-01
The contract gives the architecture review a concrete question:
Does this account still contain
the consequence it was created to contain?
Create an account when consequence should differ
This does not mean every microservice needs its own AWS account.
The target is not maximum separation.
It is useful separation.
Create another account when a meaningful difference exists in one or more of these areas:
AUTHORITY
different people or automation
must administer it
FAILURE
mistakes or compromise
should stop here
DATA
a separate classification
or protection boundary is required
POLICY
different organisation controls
must apply
QUOTAS
resource consumption
must not compete
COST
a durable owner
needs clear attribution
LIFECYCLE
the workload can be created,
transferred or retired independently
For bfstore, one account per environment may be a sensible initial model because the application remains one related product estate.
Further separation may become useful when a capability gains:
- independent ownership
- regulated data
- different lifecycle
- quota pressure
- stricter deployment authority
- customer or regional isolation
- unacceptable shared blast radius
The same application artefact may be promoted through several environments.
The code can remain consistent.
The surrounding authority should not.
Crossing the boundary is an architectural contract
An account boundary is valuable only when its crossings preserve the intended separation.
Useful crossings may include:
- role assumption
- resource policies
- network attachments
- shared DNS
- log delivery
- backup copy
- service integrations
- central platform automation
Every crossing should answer:
Who initiates it?
Which identity is used?
What may cross?
Which account owns the policy?
How is access revoked?
Which evidence is retained?
What happens when either side fails?
Cross-account IAM
A shared deployment platform may need authority in workload accounts.
That authority should be segmented by environment and purpose.
development runner
└── may assume development role
production runner
└── may assume production role
only from approved workflow context
A broad deployment role would reconnect the administrative boundaries.
Networking
Account and network boundaries solve different problems.
ACCOUNT BOUNDARY
authority
resources
quotas
cost
change
NETWORK BOUNDARY
routing
reach
packet flow
communication
A network account may operate IPAM, shared routing or DNS.
That creates a cross-account dependency.
It does not require every packet to pass through one central appliance.
Centralised management does not always require centralised traffic.
Shared platform services
Backstage, Crossplane and infrastructure automation may provide one coherent developer experience.
Their authority should remain segmented beneath that interface.
BACKSTAGE UNAVAILABLE
discovery degraded
workloads continue
CROSSPLANE UNAVAILABLE
new fulfilment blocked
existing resources continue
AUTOMATION COMPROMISED
cross-account change authority at risk
Central user experience does not require central unlimited privilege.
State and delivery systems
A shared state file covering several accounts can reconnect their operational fate.
So can:
- one unrestricted CI identity
- one universal administrator
- one repository with uncontrolled production execution
- one broad network path
MANY ACCOUNTS
plus
one universal administrator
one universal deployment role
one shared state file
one unrestricted network
equals
several invoices,
one practical failure domain
An account wall drawn in AWS but ignored by the delivery system is only partially implemented architecture.
Some accounts protect or observe others
Some accounts exist not because they run a workload, but because they must survive or observe the failure of another account.
Log archive
Audit evidence should leave the account it describes.
WORKLOAD ACCOUNT
│
├── API activity
├── configuration changes
├── network evidence
└── security events
│
▼
LOG ARCHIVE ACCOUNT
│
└── protected retention
The archive should separate:
- write authority
- read authority
- retention changes
- deletion authority
- investigation access
A central bucket is not automatically a trustworthy archive.
Backup
A backup account can separate protected copies from production administration.
bfstore-prod
│
│ approved backup copy
▼
bfstore-backup
│
├── restricted deletion
├── separate administration
└── restore testing
The independence test should ask whether production and backup still share:
- broad administrators
- identity provider
- encryption authority
- Region
- automation
- recovery documentation
A separate account reduces specific failure paths.
It does not create absolute independence.
Security tooling
A security account can retain an independent path for findings, investigation and response.
A compromised production workload should not automatically compromise the control plane used to investigate it.
Account architecture protects the system from a person’s current session, not from their résumé.
The same engineer may perform several responsibilities.
They should still assume distinct roles for them.
Organisation controls reinforce the boundary
AWS Organizations policies can reinforce account boundaries.
An OU groups accounts that should inherit the same management controls.
The account remains the administrative and resource boundary.
The OU applies policy to it.
Service control policies can bound the maximum permissions available to principals in affected member accounts.
They do not grant access.
For example, a production OU may restrict:
- use of unapproved Regions
- disabling protected logging
- prohibited public exposure
- changes to organisation-managed security controls
The precise effective-access model may also involve:
- identity policies
- resource policies
- permissions boundaries
- session policies
- key policies
- endpoint policies
- service-specific controls
Organisation policies strengthen the boundary.
They do not replace account-specific identity, trust and resource design.
Prove that the boundary still works
A boundary should be demonstrated, not merely diagrammed.
Useful tests include:
ACCESS
development role denied
in production
AUTOMATION
shared runner unable to assume
an unapproved production role
LOGGING
production activity confirmed
in protected archive
BACKUP
production administrator unable
to delete protected recovery copy
NETWORK
sandbox unable to reach
production data paths
QUOTA
critical headroom visible
and owned
RECOVERY
account dependencies and
restore path exercised
The account contract should also track freshness.
owner last verified
cross-account trust last reviewed
logging delivery last tested
quota headroom last checked
restore last demonstrated
A relationship can be correctly designed and later become stale, broad or unowned.
Test dependency failure
Cross-account relationships should document degraded behaviour.
NETWORK CONTROL PLANE UNAVAILABLE
existing routing continues
network changes blocked
SHARED SERVICES UNAVAILABLE
existing workloads continue
deployments blocked
IDENTITY PATH UNAVAILABLE
existing sessions may continue
new sessions blocked
The answer depends on the implementation.
The important point is that it is known before the incident.
A bfstore production boundary
The bfstore production account contains customer-facing workloads and production data.
It deliberately depends on several external account boundaries.
bfstore-shared-services
│
│ approved deployment role
▼
bfstore-network ───────► bfstore-prod ───────► bfstore-log-archive
│
│ protected copy
▼
bfstore-backup
The relationships are explicit.
Shared services to production
Purpose:
approved deployment and
platform reconciliation
Boundary condition:
production-specific role,
workflow and evidence
Production to log archive
Purpose:
preserve audit evidence
outside workload authority
Boundary condition:
workload administrators
cannot delete retained copies
Production to backup
Purpose:
protect recovery inputs
from production failure
Boundary condition:
separate deletion and
recovery authority
Network to production
Purpose:
provide approved routing,
DNS and connectivity
Boundary condition:
workload operators cannot
change shared network control
The structure says what bfstore believes should fail independently.
It also records where those boundaries are deliberately joined.
Questions I now ask
Consequence
Which authority, data, failure
or lifecycle should the account contain?
Workloads
Which services are related enough
to share that consequence?
Administration
Which identities and automation
may change the account?
Crossings
Which paths deliberately
penetrate the boundary?
Resources
Which quotas, cost and capacity
belong to the account?
Protection
Which logs and recovery inputs
must survive outside it?
Dependencies
Which shared systems reconnect
this account to other failure domains?
Proof
Which tests demonstrate
that the boundary remains effective?
These questions are more useful than asking how many AWS accounts a serious platform should have.
The mental model I am keeping
My earlier model was:
AWS ACCOUNT
a container for resources
and a line on the bill
The stronger model is:
AWS ACCOUNT
│
┌───────────────────┼───────────────────┐
│ │ │
▼ ▼ ▼
ADMINISTRATIVE RESOURCE INFORMATION
BOUNDARY BOUNDARY BOUNDARY
│ │ │
▼ ▼ ▼
identity resources data
trust quotas logs
change capacity backups
│ │ │
└───────────────────┼───────────────────┘
▼
OPERATING BOUNDARY
│
▼
ownership, cost and lifecycle
│
▼
OPERATIONAL BLAST RADIUS
The account boundary answers:
Which identities, resources,
costs, quotas and failures
share one administrative fate?
The crossing contract answers:
Who may penetrate that boundary,
for which purpose and with which evidence?
The verification model answers:
Does the boundary still contain
the consequence it was created to contain?
VPCs limit communication.
Clusters contain runtime and control-plane failure.
Namespaces create policy and ownership scope inside a cluster.
Accounts sit above those boundaries and contain much of the authority capable of changing them.
The account is not packaging around architectural decisions. It is one of the main tools used to make those decisions real.
Before creating the VPC, decide which account owns it.
Before creating the cluster, decide which administrative failure contains it.
Before creating the database, decide which data environment may control it.
Before granting a deployment role, decide how far its authority should reach.
And after creating the boundary, keep testing that the paths crossing it have not quietly rebuilt the failure domain it was meant to divide.