Cross-Account Access

What is cross-account access?

Cross-account access is how a principal (a user, service, or workload) in one AWS account is granted permission to act in a different AWS account — securely, and without sharing long-lived credentials. In any real AWS deployment following a multi-account strategy (separate accounts for prod, dev, security, logging, per-team, via AWS Organizations), workloads constantly need to reach across account boundaries: a CI/CD pipeline in a tooling account deploys to a production account; a central logging account collects logs from every other account; an application in one account reads an S3 bucket in another. Cross-account access is the mechanism that makes this possible while keeping the account boundary — AWS’s strongest isolation boundary — intact.

The right way: assumed roles and temporary credentials

The correct pattern is IAM role assumption, and understanding it is the whole point. Instead of creating a user in Account B and handing its long-lived access keys to Account A (the wrong, dangerous approach), you create an IAM role in the target account (Account B) whose trust policy explicitly says “principals from Account A are allowed to assume me,” and whose permissions policy grants exactly the access needed. A principal in Account A then calls sts:AssumeRole, and AWS Security Token Service returns short-lived temporary credentials for that role, which the principal uses to act in Account B for a limited time. Two policies must align for this to work — this is the frequently-confusing part: the trust policy on the role (in Account B, saying who may assume it) and an IAM policy on the calling principal (in Account A, granting permission to call assume-role). Access requires both sides to agree, which is a deliberate security property: the target account controls who can get in, and the source account controls who can attempt it. The payoff is that no permanent credentials ever cross the boundary — access is via temporary, automatically-expiring tokens, which is dramatically safer than static keys that can leak and live forever. An external ID is used when granting a third party (like a SaaS vendor) access to your account, to prevent the “confused deputy” problem. Resource-based policies (like an S3 bucket policy granting another account access) are the alternative pattern for resource-level sharing without role assumption.

The security stakes and common mistakes

Cross-account access is powerful and correspondingly sensitive — misconfigured, it’s a path for privilege escalation and lateral movement between accounts, undermining the very isolation multi-account architecture is meant to provide. The realities to respect: apply least privilege rigorously (the assumed role should grant only what’s needed, not broad admin — an over-permissive cross-account role is a hole punched straight through your account boundary); scope trust policies tightly (trust specific roles/principals, not an entire account blanketly, and never "Principal": "*"); use external IDs for third-party access; and monitor AssumeRole activity in CloudTrail, since cross-account assumption is exactly the kind of event that reveals both legitimate automation and potential compromise. SCPs in AWS Organizations can cap what cross-account roles are even permitted to do as an org-wide guardrail. The recurring mistakes are the dangerous ones: sharing long-lived access keys instead of assuming roles (the entire anti-pattern this feature exists to eliminate), overly-broad trust policies that let more principals in than intended, and excessive permissions on the assumed role that turn a foothold in one account into control over another.

What people get wrong

• Sharing static access keys across accounts — the whole point of cross-account roles is temporary, expiring credentials; long-lived shared keys are the exact risk to avoid.
• Over-broad trust policies: trusting an entire account (or *) instead of specific principals lets more in than intended — scope trust tightly and use external IDs for third parties.
• Excessive role permissions — an assumed role with broad access punches a hole through the account isolation boundary; apply least privilege so a foothold can’t become account takeover.

Primary source: AWS: Cross-account access with IAM roles