beginnerintermediateadvanced

AWS · Section 53

IAM and Multi-Account Security Architecture

Level: advanced
Read: 30 min
Concepts: 3

An AWS account is the strongest isolation boundary the platform offers: nothing crosses it without deliberate configuration — a role trust policy, a resource-based policy, or a resource share — which is what makes multi-account design a security control rather than a billing arrangement, and why the same over-broad IAM grant costs very little in a development account and a great deal in a single-account estate. On top of that boundary sit four things: SCP guardrails setting the maximum any member account may do, centralized identity through IAM Identity Center so people have one login and per-account permission sets, a log archive account and a read-only security account that hold the evidence out of reach of the workloads they observe, and a pre-created break-glass path whose safety comes from being loudly alarmed rather than difficult to use. The rule that ties it together, and the one most often misunderstood, is that an SCP grants nothing: AWS states plainly that no permissions are granted by an SCP, that effective permissions are the intersection of what the guardrails allow and what identity and resource policies allow, and that a principal with no IAM policy has no access however permissive the SCPs are. SCPs also do not apply to the management account or to service-linked roles — which is exactly why workloads do not belong in the management account.

This section

AWS re:Invent 2016: Architecting Security and Governance Across a Multi-Account Strategy (SAC319)Amazon Web Services

What is true here

The account boundary is what bounds a mistake; nothing crosses it by default.
SCP guardrails, centralized identity, a log archive account, a read-only security account, and break-glass are the four parts.
No permissions are granted by an SCP — effective permission is an intersection, and any explicit deny wins.
SCPs do not affect the management account or service-linked roles.
Test SCPs on an OU, and never remove FullAWSAccess without a replacement.

What you will be able to do

Explain what crosses an account boundary and what configuration each mechanism requires
Lay out an account structure with security and log archive accounts and no workloads in the management account
Write a guardrail SCP, test it safely, and tighten it using service last accessed data
Design a break-glass path that is usable in an outage and impossible to use quietly
Work out effective permissions across SCPs, boundaries, and identity and resource policies

From account boundaries to guardrails that behave as expected

Identity boundaries across accounts

Guardrails, central security, break-glass

SCPs constrain, never grant

IAM and Multi-Account Security Architecture

Account boundaries as the primary isolation control, the guardrail and central-security machinery built on them, and what a service control policy actually does.

Identity Boundaries Across Accounts

coreadvanced

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.

Think of it as

Accounts are separate buildings, not separate rooms. A mistake inside one — an over-broad role, a public bucket, a compromised credential — stays inside it unless a door was built. IAM inside an account is fine-grained and easy to get subtly wrong; the account boundary is coarse and hard to cross by mistake.

What we're doing: Compare the blast radius of the same mistake in one account and in several.

blast-radius.txttext

Single account: a developer role is granted a wildcard S3 policy for
convenience during an investigation. That role can now read production
customer data, the CloudTrail bucket, and the backups — all of which
live in the same account.

Multi-account: the same wildcard is granted in the development account.
It covers exactly the development account's buckets. Production data,
audit logs, and backups are in other accounts and are unaffected,
because no trust relationship extends the role there.

Same mistake, same person, completely different consequence.

1: The over-broad grant is a normal, well-intentioned mistake. Designing so that it stays cheap is the point.
6: Nothing prevented the mistake in either case. The account boundary is what bounded it.

Why this works: Fine-grained IAM inside one account is necessary and will still be got wrong occasionally, because policies are subtle and pressure is real. The account boundary is coarse, hard to cross accidentally, and is what determines the cost of those inevitable errors.

Running workloads in the management account

Wrong

text

# The management account also hosts the shared services and a couple of
# small production workloads

Better

text

# The management account holds the organization and billing only.
# Workloads live in member accounts.

What you see: A guardrail that protects every other account does not apply here, and a compromise in that workload reaches the organization itself.

Why: AWS documents that SCPs do not affect users or roles in the management account — they apply only to member accounts. A workload there is therefore outside every organization-wide guardrail, in the one account that can modify the organization.

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

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

Together

json

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::111122223333:role/deploy-pipeline" },
    "Action": "sts:AssumeRole",
    "Condition": { "StringEquals": { "sts:ExternalId": "prod-deploy" } }
  }]
}

Remember: 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.

Guardrails, Central Security, and Break-Glass

coreadvanced

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.

Think of it as

Guardrails are the fence, identity is the gate, the security account is the camera room, and break-glass is the key in the sealed box by the door. Each is useless without the others, and the sealed box only works because opening it is noisy.

What we're doing: Design a break-glass path that is safe to have and impossible to misuse quietly.

break-glass.txttext

The role exists before it is needed: a pre-created role in each critical
account, trusted only by a specific named principal, with MFA required.

Credentials are sealed: stored offline or in a separate vault, held by
two people, retrieved together rather than individually.

Use is loud: an EventBridge rule on AssumeRole for that role pages the
security on-call and posts to a channel, unconditionally.

Use is reviewed: every use produces a short write-up naming who, why,
and what was done — the same day, not at the next audit.

1: Creating the role during the incident requires the access you have lost. It has to exist beforehand or it is not a break-glass path.
5: Two people is what makes it a deliberate act rather than a convenient shortcut for one person under pressure.
9: The alarm is the entire safety mechanism. A break-glass path used silently is just an unmonitored administrator.

Why this works: Every access system will be unavailable at some point — an identity provider outage, a misapplied SCP, a locked-out administrator. A break-glass path acknowledges that. What makes it safe is not difficulty of use but the certainty that use is seen immediately.

Attaching a new SCP at the organization root

Wrong

text

# Attach the new deny policy at the root to cover everything at once

Better

text

# Create a test OU, move accounts in one at a time, and use service
# last accessed data to check what the policy would actually block

What you see: A service nobody remembered was in use stops working across every account simultaneously, including the accounts needed to diagnose it.

Why: AWS strongly recommends against attaching SCPs to the root without thorough testing, and suggests exactly this incremental OU approach. A root-level SCP applies everywhere at once, so a mistake has no unaffected account left to work from.

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

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

Together

json

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyDisablingSecurityServices",
    "Effect": "Deny",
    "Action": [
      "cloudtrail:StopLogging", "cloudtrail:DeleteTrail",
      "guardduty:DeleteDetector", "config:DeleteConfigurationRecorder"
    ],
    "Resource": "*"
  }]
}

Remember: 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.

SCPs Constrain — They Never Grant

coreadvanced

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.

Think of it as

An SCP is a ceiling, not a floor. Raising a ceiling lets nothing through on its own — someone still has to build up to it. Lowering it, on the other hand, cuts off whatever was above, regardless of what any account administrator has granted.

What we're doing: Debug "the SCP allows it but it still fails".

scp-confusion.txttext

Report: "We added s3:PutObject to the SCP and the role still cannot
write."

Check 1: the SCP now allows s3:PutObject. Correct, and irrelevant on its
own — the SCP is a ceiling.

Check 2: the role's identity policy grants s3:GetObject only. There is
no grant for PutObject anywhere.

Fix: add s3:PutObject to the role's identity policy. The SCP change was
necessary and not sufficient.

1: This is the single most common SCP misunderstanding, and it comes from the two policy types sharing a syntax.
5: Raising a ceiling changes what is possible, not what is permitted.
9: Both changes are needed when the SCP was previously the binding constraint — the order does not matter, but neither alone works.

Why this works: SCPs use almost the same syntax as IAM policies, so an `Allow` in one reads like a grant. Internalising "ceiling, never floor" turns a confusing class of failures into a two-line check.

Relying on an SCP to protect the management account

Wrong

text

# Deny SCP at the root, assumed to cover every account including the
# management account

Better

text

# Protect the management account separately: minimal users, no
# workloads, MFA everywhere, and its own monitoring

What you see: A guardrail believed to be organization-wide has a hole in the one account that can modify the organization, and nothing reports the gap.

Why: AWS documents this twice over: SCPs affect only member accounts, and no action performed by the management account can be restricted by an SCP. Any control model that assumes otherwise has an unprotected root.

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

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

Together

text

# The four-way check for "why can't this role do X?"
1. Is there an explicit Deny anywhere?      (SCP, RCP, IAM, resource)
2. Does the SCP allow the action?           (ceiling)
3. Does a permissions boundary allow it?    (if attached)
4. Does an identity or resource policy allow it?  (the actual grant)

Remember: 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.