AWS Cross-Account IAM Architecture

The Sovereign Bridge of the Enterprise

Cross-Account IAM is the “Sovereign Bridge” of the multi-account AWS enterprise. In a modern cloud strategy, organizations isolate workloads into hundreds of separate AWS accounts to limit the “blast radius” of any single breach. However, this isolation creates a massive identity challenge: How do administrators and automated tools navigate this archipelago of accounts? For the IAM architect, Cross-Account IAM is the framework for Federated Governance, using Trust Relationships and the “Assume Role” pattern to establish a secure, auditable, and centralized command-and-control plane.

CROSS-ACCOUNT

Governance Sovereign

Core Mission

Administrative Centralization. Establishing a cryptographically secure method for principals in a "Trusted Account" to access resources in a "Target Account" without persistent credentials.

Like a Diplomatic Passport System: Imagine a cluster of independent islands (Your AWS Accounts). You are a citizen of the "Security Island" (Central Hub). You don't need a citizenship on every other island to visit. Instead, you carry a "Sovereign Diplomatic Passport" (Your Central Identity). Each other island has a "Treaty" (The Trust Policy) that says: "We trust anyone with a valid passport from the Security Island to perform specific tasks." You present your passport, and they give you a temporary "Day Pass" (STS Token) to go to work.

Centralized Security Hub / Shared Service Accounts / Multi-Account Org Governance / Managed MSP Access

The Multi-Account Strategy Matrix

Designing for cross-account access requires a structured approach to trust and organizational guardrails.

Strategic Governance Profiles

Profile	Strategic Responsibility	IAM Implementation
Centralized Security Hub	One Account to Rule Them All.	Central account containing all “Human” IAM Users or IdP federation.
Trust Policy (Sovereign)	The Treaty Definition.	Rigid JSON logic in the Target account defining the Trusted account principal.
Identity Delegation	The Access Permit.	Permissions in the Trusted account allowing users to call sts:AssumeRole.
Full Stack Isolation	Maximum Blast Radius Control.	No cross-account trust allowed; each account is an independent sovereign entity.

The Cross-Account Handshake Flow

Navigating between accounts involves a three-way handshake between the source principal, the target role, and the AWS Security Token Service (STS).

graph LR
    Trusted[Principal in Account A] --> STS[Request AssumeRole: Account B]
    STS --> Validate[Validate Trust Treaty]
    Validate --> Creds[Issue Temp Creds for B]

1

Establish the Sovereign Treaty

In the **Target Account (B)**, create an IAM Role. Attach a **Trust Policy** that explicitly allows the root principal of **Source Account (A)** to assume it. This "Open Door" is restricted to a specific account ID, ensuring only your company's hub can initiate the handshake.

2

Grant the Diplomatic Permit

In the **Source Account (A)**, grant your user or application the permission to call `sts:AssumeRole` targeting the ARN of the role in Account B. This is the user's "Permit to Travel" across the organizational boundary.

3

Assume & Execute

The user executes the `aws sts assume-role` command. AWS validates both the Permit in A and the Treaty in B. If both align, STS issues temporary credentials. The user now "Becomes" the role in Account B, performing their task with an audit trail that points back to their original identity in A.

---

Technical Cross-Account Implementation

Automating the rollout of cross-account roles ensures that new accounts are “Born Secure.”

Cross-Account Role Design (Terraform Example)

# In TARGET Account (B): Create the Role and Trust Policy
resource "aws_iam_role" "cross_account_admin" {
  name = "SovereignSecurityAdmin"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Action = "sts:AssumeRole"
      Effect = "Allow"
      Principal = { AWS = "arn:aws:iam::111222333444:root" } # Central Account A
    }]
  })
}

# Attach Permissions to the Role
resource "aws_iam_role_policy_attachment" "admin_attach" {
  role       = aws_iam_role.cross_account_admin.name
  policy_arn = "arn:aws:iam::aws:policy/AdministratorAccess"
}

Cross-Account Implementation Guides

Master the technical ceremonies of multi-account governance and trust delegation.

Identity Center

Using AWS SSO as the modern, high-scale alternative to manual cross-account roles.

External ID Support

Implementing 'External IDs' for secure cross-account trust with third-party vendors.

Org Guardrails

Using Service Control Policies (SCP) to prevent the modification of sovereign cross-account roles.

Forensic Triage

Architecting cross-account roles for rapid incident response and centralized logging.

Next Steps

• Explore AWS Cross-Account Access Tutorial for deep dive docs.
• Review AWS Control Tower for automating multi-account factory rollouts.
• Check Resource Access Manager (RAM) for sharing resources without complex IAM trust.