beginnerintermediateadvanced

AWS · Multi-Account Security

IAM and Multi-Account Security Architecture

Account boundaries, guardrails and central security, and what an SCP actually does

The account is the boundarynothing crosses it without configuration
SCPs skip the management accountso no workloads belong there
SCPs grant nothingthey set the ceiling; IAM is the grant
Break-glass is loud, not hardthe alarm is the safety mechanism

1.Identity Boundaries Across Accounts

An AWS account is the strongest isolation boundary AWS offers. Permissions do not cross it by accident: a principal in one account has no access to another unless someone deliberately established the trust. That property is what makes multi-account architecture a security control rather than a billing arrangement.

Key features

Cross-account access requires both sides to agree: the trusting account's role trust policy, and the calling principal's own permission to assume it
A resource-based policy (an S3 bucket policy, a KMS key policy) can also grant access across accounts, without a role assumption
AWS Organizations does not itself grant access — it groups accounts and applies policy, and the management account is administratively special rather than universally powerful
The usual account set is production, non-production, a security account, a log archive account, and a shared-services account, plus one per significant workload
IAM Identity Center centralizes human identity so people have one login and per-account permission sets rather than a user in each account
A blast-radius question answers itself in a multi-account design: a compromise is bounded by the account unless a trust relationship extends it

What crosses an account boundary, and what it takes

What crosses an account boundary, and what it takes
Mechanism	Configured where	Typical use
Role assumption	Trust policy on the role + permission on the caller	A pipeline in shared services deploying to production
Resource-based policy	On the resource (bucket, key, queue)	A log archive bucket accepting an organization trail
Resource sharing (RAM)	On the sharing account	Sharing subnets from a networking account
VPC peering / Transit Gateway	Network, not identity	Connectivity — grants no permissions at all
Nothing else	—	Two accounts with no configuration share no access

A typical account layout

Governed by the organization

Management account

organization, billing — no workloads

Security account

GuardDuty, Security Hub, read access everywhere

Log archive account

CloudTrail, config, and access logs

Where work happens

Production accounts

one per workload where it matters

Non-production accounts

staging, development, sandboxes

Shared services

CI/CD, networking hub, artifacts

Signature

account = the isolation boundary · crossing it needs a trust policy, a resource policy, or a share — never a default

The account is the strongest isolation boundary AWS offers, and nothing crosses it without explicit configuration — a role trust policy, a resource-based policy, or a share. Keep workloads out of the management account, and centralize human identity rather than duplicating users per account.

2.Guardrails, Central Security, and Break-Glass

A multi-account security architecture has four moving parts. Guardrails (SCPs) set the maximum any account may do. Centralized identity gives people one login and per-account permission sets. Dedicated security and log archive accounts hold the evidence out of reach of the workloads they observe. And a break-glass path exists for the day the normal path is unavailable.

Key features

SCPs are attached to the root, an organizational unit, or an account, and an account has only the permissions allowed by every parent above it
AWS strongly recommends not attaching an SCP to the organization root without testing, and suggests moving accounts into a test OU one at a time
Do not remove the `FullAWSAccess` policy unless you replace it — otherwise all AWS actions from member accounts fail
Service last accessed data in IAM shows which allowed services are never used, which is how an SCP gets tightened toward least privilege with evidence
A log archive account holds CloudTrail and other audit logs so a compromised workload role has no path to the record of the compromise
A security account runs the detective services with read access across the organization and hosts no workloads, while break-glass is a rarely-used, heavily-alarmed path whose value comes from being noisy rather than hard to use

The four parts, and what each one is for

The four parts, and what each one is for
Part	Mechanism	Failure if missing
Guardrails	SCPs on OUs, tested before the root	An account administrator can do anything, including disabling logging
Centralized identity	IAM Identity Center + permission sets	Per-account users, no single revocation point
Log archive account	Organization trail into a locked-down bucket	The evidence lives where the compromise happened
Security account	GuardDuty / Security Hub, org-wide read	Findings are per account and nobody sees the whole picture
Break-glass	A pre-created role, sealed credentials, loud alarms	An outage of the identity provider is also an outage of access

What has to be true for an action to happen

SCP (and RCP) allows it

The organizational guardrail — grants nothing on its own

Permissions boundary allows it

If one is attached to the principal

Identity-based policy allows it

The actual grant

Resource-based policy allows it

Where the resource has one

No explicit deny anywhere

A deny at any level wins

Signature

SCP guardrails + Identity Center + log archive account + read-only security account + alarmed break-glass

Guardrails (SCPs, tested on an OU before the root), centralized identity with per-account permission sets, a log archive account the workloads cannot reach, a read-only security account, and a pre-created break-glass role whose use is loud. Never remove `FullAWSAccess` without a replacement.

3.SCPs Constrain — They Never Grant

A service control policy looks like an IAM policy and behaves nothing like one. AWS states it plainly: no permissions are granted by an SCP. An SCP sets the maximum available permissions for the IAM users and roles in an account. The actual grant still has to come from an identity-based or resource-based policy.

Key features

AWS states directly: SCPs do not grant permissions to the IAM users and IAM roles in your organization; no permissions are granted by an SCP
Effective permissions are the intersection of what the SCPs (and RCPs) allow and what the identity-based and resource-based policies allow
A user with no IAM permission policy has no access even if the SCPs allow every service and every action
An account has only the permissions permitted by every parent above it — a deny at any level, explicit or implicit, wins
SCPs apply to member accounts including their root user, but have no effect on users or roles in the management account
SCPs do not affect service-linked roles, resource-based policies directly, or principals from outside the organization — and where a permissions boundary is also present, the boundary, the SCP, and the identity-based policy must all allow the action

Effective permission, worked through

Effective permission, worked through
SCP says	IAM policy says	Result
Allow s3:*	Allow s3:GetObject	GetObject allowed — the intersection
Allow s3:GetObject	Allow s3:*	GetObject only — the SCP is the ceiling
Allow s3:*	Nothing attached	No access — nothing granted it
Deny s3:DeleteObject	Allow s3:* (AdministratorAccess)	DeleteObject denied, even for the root user
Allow s3:*, in the management account	Allow s3:*	Allowed — SCPs do not apply to the management account

Two policies that look alike and do opposite things

SCP — a ceiling

Grants nothing, ever
Sets the maximum available permissions
Applies to member accounts, not the management account
Does not affect service-linked roles

IAM identity policy — a grant

Is the actual permission
Attached to a user or role
Useless above what the SCP allows
Required — an SCP allowing everything grants nothing

Signature

effective = SCP ∩ permissions boundary ∩ identity/resource policy · explicit Deny always wins · SCP grants nothing

No permissions are granted by an SCP — it sets the maximum. Effective permission is the intersection of SCP, permissions boundary, and identity/resource policy, with any explicit deny winning. SCPs skip the management account and service-linked roles, and removing `FullAWSAccess` without a replacement breaks everything.

Spotted a mistake on this page? Tell us.

Read Sheet