Demo Cross Account Roles and How to Assume Them

This guide demonstrates how a user in one AWS account (Account B) can assume a role in another AWS account (Account A) to access Amazon S3 resources. It covers the required trust policy, role permission policy, and the user policy that allows sts:AssumeRole. This pattern is commonly used for cross-account access, least-privilege delegation, and temporary credential issuance. Key concepts: cross-account role, trust policy (Principal + sts:AssumeRole), permission policy (what the role can do), and the caller policy that permits sts:AssumeRole.

Environment (accounts & principals)

Account	Role / User	Identifier
Account A (role owner)	Role to create	`CrossAccountS3ReadRole` — Account ID: `635573991785`
Account B (caller)	IAM user	`arnold2` — Account ID: `466456867028`

Overview / Flow

In Account A, create an IAM role with a trust policy that explicitly allows the user arnold2 in Account B to assume it.
Attach an S3 read-only permission policy to the role (e.g., AmazonS3ReadOnlyAccess).
In Account B, attach an inline or managed policy to arnold2 allowing sts:AssumeRole on the role ARN in Account A.
The user arnold2 can then assume the role via Console (Switch Role), CLI, or SDK and perform actions permitted by the role (read-only S3 in this demo).

When creating cross-account trust, lock the trust policy to the smallest set of principals necessary. Using explicit ARNs (like arn:aws:iam::466456867028:user/arnold2) is safer than wildcards.

Step 1 — Create the cross-account role in Account A

Sign in to Account A (635573991785).
Open the IAM console → Roles → Create role.
Choose to create a role with a custom trust policy (replace the default). The trust policy must allow the specific principal (the user arnold2 in Account B) to call sts:AssumeRole.

Example trust policy (paste into the trust policy editor):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::466456867028:user/arnold2"
      },
      "Action": "sts:AssumeRole",
      "Sid": ""
    }
  ]
}

This policy grants the IAM user arnold2 in Account B permission to assume the role.

Step 2 — Attach permissions to the role

After creating the role and configuring the trust policy, attach a permission policy granting S3 read access. For this demo we attach the AWS managed policy AmazonS3ReadOnlyAccess.
Give the role a descriptive name such as CrossAccountS3ReadRole and finish role creation.

Note: You can alternatively create a custom inline policy for the role if you need to restrict access to specific buckets or prefixes.

Step 3 — Give the user in Account B permission to assume the role

In Account B (466456867028) attach an inline policy (or a managed policy) to the IAM user arnold2 that allows sts:AssumeRole on the role ARN in Account A. Example policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::635573991785:role/CrossAccountS3ReadRole"
    }
  ]
}

This policy grants arnold2 the ability to call AssumeRole on CrossAccountS3ReadRole. Optional: If you prefer CLI verification, the user can call aws sts assume-role once they have this permission: Example (run as arnold2 with regular credentials configured):

aws sts assume-role \
  --role-arn arn:aws:iam::635573991785:role/CrossAccountS3ReadRole \
  --role-session-name arnold2-session

The output returns temporary credentials (AccessKeyId, SecretAccessKey, SessionToken) that can be exported as environment variables to make API/CLI calls as the assumed role. For example:

export AWS_ACCESS_KEY_ID=...
export AWS_SECRET_ACCESS_KEY=...
export AWS_SESSION_TOKEN=...
aws s3 ls

Step 4 — Switch role in the Console and verify access

Sign in as the user arnold2 in Account B.
Use the Console “Switch Role” feature. Enter the Account ID of Account A (635573991785) and the role name CrossAccountS3ReadRole. Optionally set a display name and color for the session.

A screenshot of the Amazon Web Services "Switch Role" webpage showing an Account ID field and an IAM role name/color selection dropdown (options like None, Red, Orange, Yellow, Green, Blue). The bottom right shows Cancel and Switch Role buttons.

After switching, the Console session runs with the role’s permissions. Navigate to S3 to view the buckets in Account A and read objects as allowed by the role.

A screenshot of the Amazon S3 web console showing the "General purpose buckets" view with a list of S3 bucket names, their AWS region and creation dates. The top bar shows actions like Copy ARN, Empty, Delete and an orange "Create bucket" button.

Because the role has AmazonS3ReadOnlyAccess, you can open buckets and view objects, but write/create actions are not permitted.

Step 5 — Verify permissions (attempt an action outside allowed permissions)

While using the assumed role, try to create a bucket. Since the role is read-only, s3:CreateBucket is not permitted and the action will fail with an access error.

Screenshot of the Amazon S3 "Create bucket" console. It displays a red error message: "Failed to create bucket" because the s3:CreateBucket permission is required, with the Advanced settings panel and a "Diagnose with Amazon Q" button visible.

To confirm role permissions, inspect the role in the IAM console of Account A. You should see AmazonS3ReadOnlyAccess (or whichever policies you attached).

A screenshot of the AWS Identity and Access Management (IAM) console on the Roles page for "CrossAccountS3ReadRole," showing its Permissions policies. The policy list includes the AmazonS3ReadOnlyAccess managed policy and controls like Simulate, Remove, and Add permissions.

Summary (quick reference)

Component	Purpose
Trust policy (role in Account A)	Specifies who can assume the role — `Principal` + `sts:AssumeRole`.
Permission policy (role in Account A)	Defines what actions the assumed role can perform (e.g., `AmazonS3ReadOnlyAccess`).
Caller/user policy (user in Account B)	Allows the user to call `sts:AssumeRole` on the role ARN in Account A.
Console Switch Role / CLI / SDK	Methods to assume the role and obtain temporary credentials.

Best practice: Apply least privilege. Restrict trust to specific principals and limit role permissions to only the required actions and resources (e.g., specific S3 bucket ARNs and prefixes).

Links and references

IAM roles and trusting third-party or cross-account principals: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html
sts:AssumeRole API: https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html
Console Switch Role documentation: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html
Amazon S3 documentation: https://docs.aws.amazon.com/s3/index.html

Introduction

Domain 1 - SDLC Automation

Domain 2 - Configuration Management and IaC

Domain 3 - Resilient Cloud Solutions

Domain 4 - Monitoring and Logging

Domain 5 - Incident and Event Response

Domain 6 - Security and Compliance

Demo Cross Account Roles and How to Assume Them

Environment (accounts & principals)

Overview / Flow

Step 1 — Create the cross-account role in Account A

Step 2 — Attach permissions to the role

Step 3 — Give the user in Account B permission to assume the role

Step 4 — Switch role in the Console and verify access

Step 5 — Verify permissions (attempt an action outside allowed permissions)

Summary (quick reference)

Links and references

Watch Video

​Environment (accounts & principals)

​Overview / Flow

​Step 1 — Create the cross-account role in Account A

​Step 2 — Attach permissions to the role

​Step 3 — Give the user in Account B permission to assume the role

​Step 4 — Switch role in the Console and verify access

​Step 5 — Verify permissions (attempt an action outside allowed permissions)

​Summary (quick reference)

​Links and references

Watch Video

Environment (accounts & principals)

Overview / Flow

Step 1 — Create the cross-account role in Account A

Step 2 — Attach permissions to the role

Step 3 — Give the user in Account B permission to assume the role

Step 4 — Switch role in the Console and verify access

Step 5 — Verify permissions (attempt an action outside allowed permissions)

Summary (quick reference)

Links and references