Cross-Account Access: Resource-Based Policies vs IAM Roles

There are two ways to give an identity in one AWS account access to something in another: put a resource-based policy on the resource, or have the identity assume a role in the account that owns it. This page is the decision between them.

The mechanics of role assumption — trust policies, permission policies, sts:AssumeRole and troubleshooting — are covered in Understanding cross-account IAM roles.

Resource-based policies

A resource-based policy is attached to the resource itself and names the principals allowed to use it. Amazon S3 buckets, SQS queues, SNS topics, KMS keys, Secrets Manager secrets, Lambda functions and several other services support them.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowPartnerAccountRead",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::123456789012:role/PartnerReadRole"
            },
            "Action": [
                "s3:GetObject",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::example-bucket",
                "arn:aws:s3:::example-bucket/*"
            ]
        }
    ]
}

The principal here is a specific role in account 123456789012. Naming arn:aws:iam::123456789012:root instead would delegate the decision to that account’s administrators, who could then grant the access to anyone in it — occasionally what is wanted, usually not.

Suits

• Sharing one resource, or a small set, with a known account
• Service-to-service access where the calling service reads the resource directly
• Public or anonymous access, which a role cannot provide
• Services that cannot assume a role

Advantages

• No role switch: the caller uses its own credentials and reads the resource directly
• Fewer moving parts for a simple share
• Both s3:ListBucket on the bucket and s3:GetObject on the objects can be expressed in one document

IAM roles

The identity in the calling account assumes a role in the account that owns the resources, and receives temporary credentials scoped to that role.

Suits

• Access to many resources or many services, where a policy per resource would not scale
• Anything requiring MFA, an external ID, or session-level constraints
• Human access — an engineer working across development, staging and production accounts
• Applications in one account operating on resources in another

Advantages

• Temporary credentials that expire
• Permissions managed in one place — the role — rather than on every resource
• Conditions on the trust policy: MFA present, an external ID, a specific organisation ID, a source network
• Every assumption is a distinct CloudTrail event with a session name, so activity is attributable

Decision matrix

Requirement	Resource-based policy	IAM role
Temporary credentials	No	Yes
Access spanning many resources or services	Poorly — one policy per resource	Yes
Service-to-service access	Yes	Yes, where the service can assume a role
Anonymous or public access	Yes	No
Session-level control and revocation	No	Yes
MFA enforcement	Only through a condition on the caller	Yes, in the trust policy
External ID for third-party access	No	Yes
Attributable per-session audit trail	Partial	Yes

Practice

Security

• Name the specific role or user in a Principal, not the account root, unless delegating deliberately
• Constrain with conditions: aws:PrincipalOrgID, aws:SourceIp, aws:MultiFactorAuthPresent, an external ID for third parties
• Review cross-account grants on a schedule. IAM Access Analyzer reports every resource reachable from outside the account or organisation, which is the fastest way to find the ones nobody remembers creating

Organisation

• Record every cross-account relationship: which account, which resource, why, and who owns the review
• Use consistent naming so that a role’s purpose is visible from its ARN in a CloudTrail event

Monitoring

• CloudTrail across both accounts, aggregated centrally
• Alarms on role assumptions from unexpected sources
• Periodic review of the access patterns the grants actually produce

Rules of thumb

• One resource, one partner account, read-only — a resource-based policy.
• A team working across several accounts — a role, assigned through IAM Identity Center.
• A third party needing access to your account — a role, with an external ID.
• Anything that must be reachable anonymously — a resource-based policy; a role cannot do it.