Cross-Account Roles and Resource Policies

Real architectures span many accounts: a production account, a logging account, a shared-services account. Workloads and people often need to reach resources across these boundaries.

The secure way is never to copy credentials between accounts. Instead, you grant scoped access using cross-account roles or resource-based policies.

The most common pattern is a role in the target account that a principal in the source account assumes.

• The role's trust policy names the source account or principal.
• The source principal calls AssumeRole and receives temporary credentials.
• It then acts in the target account within the role's permissions.

Cross-account role assumption requires both sides to permit it:

• The target role's trust policy allows the source principal.
• The source principal's identity policy allows sts:AssumeRole on that role.

If either is missing, the assumption fails. This double check is a frequent exam point.

Some services support resource-based policies attached directly to the resource, such as an S3 bucket policy, KMS key policy, or SQS queue policy.

These can grant access to a principal in another account without that principal assuming a role. The external account uses its own identity and the resource policy authorizes it.

Choose the mechanism by the service:

• For services with no resource policy (EC2, most APIs), use a cross-account role.
• For S3, KMS, SNS, SQS, Lambda, and others, a resource policy can grant direct cross-account access.

Resource policies avoid an extra AssumeRole hop.

When granting a third party (like a SaaS vendor) cross-account access, add an external ID condition to the trust policy.

The vendor must pass a unique secret value when assuming the role. This blocks the confused deputy problem, where an attacker tricks the vendor into accessing the wrong customer's account.

Cross-account roles should grant the minimum needed, scoped to specific resources and actions.

A common mistake is a broad trust to an entire external account combined with administrator permissions. Tighten the trust to a specific role or user, and the permissions to the exact task.

A frequent design centralizes a function in one account that others reach via roles, for example a security account assuming read-only roles into every workload account.

Each workload account hosts an identically named role trusting the security account, so tooling can scan all accounts uniformly.

AWS Resource Access Manager (RAM) shares specific resources, like subnets or Transit Gateways, across accounts in an organization.

RAM is for sharing the resource itself rather than granting API permissions to act on it. It complements roles and resource policies for network and infrastructure sharing.

Cross-account access widens your trust surface, so audit it regularly.

• CloudTrail records every AssumeRole and cross-account API call.
• IAM Access Analyzer flags resource policies that grant access outside your account.

Review these to catch unintended sharing early.

To connect accounts securely: prefer roles for compute and APIs, resource policies for storage and messaging services, and always apply least privilege with an external ID for third parties.

Never share long-term keys between accounts.

Reason about cross-account access.

You learned how to connect accounts safely.

• Cross-account roles need both a trust policy and a source identity policy.
• Resource-based policies grant direct access for services like S3 and KMS.
• Use an external ID for third parties and audit with Access Analyzer and CloudTrail.