Cross-Account Access

Cross-Account Access allows users, roles, or services in one AWS account to access resources in another account. The recommended approach is creating an IAM role in the target account with a trust policy that allows the source account to assume it. Done well, cross-account access is what makes a multi-account strategy workable: no shared long-lived credentials, every access temporary and logged. Done badly, it quietly turns your account boundary, the strongest isolation primitive AWS gives you, into a suggestion.

Methods

• IAM Roles: the recommended approach; temporary credentials, auditable via CloudTrail
• Resource-based policies: S3 bucket policies, SQS queue policies, KMS key policies can grant cross-account access directly
• AWS RAM: share resources (subnets, Transit Gateways, License Manager configs) across accounts
• AWS Organizations: trusted access for services like CloudTrail, Config, GuardDuty across the org

How Role Assumption Works Across Accounts

Two policies have to agree before an identity in account A can act in account B. The role in account B carries a trust policy naming who may assume it, and the caller in account A needs an identity policy allowing sts:AssumeRole on that role's ARN. The caller then exchanges its own credentials for temporary credentials scoped to the role. Sessions default to one hour and can be extended up to the role's configured maximum, which is capped at 12 hours; a role assumed from another role (role chaining) is limited to one hour regardless. For third parties, add an external ID to the trust policy: a shared string, between 2 and 1224 characters, that the third party must present on every assume call. It exists to defeat the confused deputy problem, where a vendor with many customers could otherwise be tricked into using its access to your account on someone else's behalf.

How It Goes Wrong in Practice

The recurring misconfiguration is the over-trusting trust policy. Common variants: a trust policy whose principal is an entire account root (arn:aws:iam::111122223333:root) when only one specific role in that account should qualify, meaning any principal in the partner account with sts:AssumeRole permissions can walk in; a vendor integration configured without an external ID, leaving the confused deputy door open; and the worst case, a principal of "AWS": "*" left over from debugging, which makes the role assumable from any AWS account on the planet if the caller knows the ARN. Attackers actively enumerate role ARNs against known account IDs looking for exactly this. Because trust policies are written once during an integration and rarely revisited, these grants outlive the projects that justified them. IAM Access Analyzer exists for this reason: it continuously flags roles and resources whose policies allow access from outside your zone of trust.

A Practical Check: Assuming and Auditing

Verifying a cross-account role behaves as intended is a one-liner:

aws sts assume-role --role-arn arn:aws:iam::111122223333:role/PartnerAccess --role-session-name audit-test --external-id Example123

--role-arn and --role-session-name are required; --external-id must match what the trust policy demands, and --duration-seconds accepts 900 to 43200 seconds subject to the role's maximum. Just as important is the audit trail: every assumption lands in the target account's CloudTrail as an AssumeRole event, with the session name you passed. Enforce meaningful session names (user IDs, ticket numbers) so the trail answers "who was this, really" instead of showing a wall of session1.

Frequently Asked Questions

When should I use a resource-based policy instead of a role?

A resource-based policy is simpler when a principal in another account needs access to one specific resource, an S3 bucket or SQS queue, while keeping its own identity and its own permissions elsewhere. A role is better when the caller needs to operate broadly inside your account, because you control exactly what the assumed session can do and everything happens under an identity you own.

How long can a cross-account session last?

Default one hour. You can request up to the role's configured maximum session duration, which the role owner can set anywhere from 1 to 12 hours. Role chaining caps the session at one hour regardless of settings.

How do I find out which of my roles are exposed to other accounts?

Enable IAM Access Analyzer. It analyzes trust policies and resource policies and generates findings for every role, bucket, key, or queue that grants access outside your account or organization, including the wildcard-principal cases you most need to catch.