When working with AWS organizations that use multiple accounts, developers often need to assume IAM roles across accounts. The web console makes this easy with its "Switch Role" feature, but CLI operations require proper configuration.

Before proceeding, ensure you have:

1. Valid credentials for your base account (Login account)

2. The ARN of the target role in the Project account

3. A recognizable session name for auditing

4. The external ID if required by the trust policy

There are two primary methods to assume roles in AWS CLI:

Method 1: Direct Assume-Role Command

aws sts assume-role \
    --role-arn "arn:aws:iam::PROJECT_ACCOUNT_ID:role/YourProjectRole" \
    --role-session-name "YourSessionName" \
    --external-id "OptionalExternalID"

This returns temporary credentials you can export:

export AWS_ACCESS_KEY_ID=ASIA...
export AWS_SECRET_ACCESS_KEY=...
export AWS_SESSION_TOKEN=...

Method 2: Config File Setup

Create or modify your ~/.aws/config file:

[profile project-role]
source_profile = default
role_arn = arn:aws:iam::PROJECT_ACCOUNT_ID:role/YourProjectRole
external_id = OptionalExternalID
region = us-west-2

Then use the profile with any AWS CLI command:

aws s3 ls --profile project-role

AccessDenied: Verify the trust relationship allows your base account to assume the role.

InvalidClientTokenId: Check your base account credentials.

ExpiredToken: Temporary credentials last only 1 hour by default.

For frequent switching, create a helper script:

#!/bin/bash
eval $(aws sts assume-role \
    --role-arn "arn:aws:iam::$1:role/$2" \
    --role-session-name "$3" \
    --query 'Credentials.[AccessKeyId,SecretAccessKey,SessionToken]' \
    --output text | \
    awk '{print "export AWS_ACCESS_KEY_ID="$1"\nexport AWS_SECRET_ACCESS_KEY="$2"\nexport AWS_SESSION_TOKEN="$3}')

1. Always use MFA for role assumption when possible

2. Set session duration limits in IAM policies

3. Regularly rotate your base account credentials

4. Use external IDs when assuming roles across accounts

When working in multi-account AWS environments, developers often need to assume roles across accounts while restricted to credentials from a single "jump" account. Here's how to configure AWS CLI for seamless role switching without requiring direct access keys in the target account.

You'll need:

• Valid credentials for your base account (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY)
• The ARN of the target role you need to assume (format: arn:aws:iam::TARGET_ACCOUNT_ID:role/ROLE_NAME)
• The external ID if required by the trust policy

Edit your AWS credentials file (~/.aws/credentials) to set up profile chaining:

[login-account]
aws_access_key_id = AKIAXXXXXXXXXXXXXXXX
aws_secret_access_key = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

[project-role]
role_arn = arn:aws:iam::123456789012:role/ProjectAdmin
source_profile = login-account
region = us-west-2
# Optional if required by trust policy:
external_id = ABCDEF123456

For temporary access without permanent profile configuration:

aws sts assume-role \
--role-arn "arn:aws:iam::123456789012:role/ProjectAdmin" \
--role-session-name "CLISession" \
--profile login-account

For long-running processes, use a wrapper script to handle token expiration:

#!/bin/bash
CREDS=$(aws sts assume-role \
         --role-arn arn:aws:iam::123456789012:role/ProjectAdmin \
         --role-session-name "AutomatedSession" \
         --query 'Credentials.[AccessKeyId,SecretAccessKey,SessionToken]' \
         --output text)

export AWS_ACCESS_KEY_ID=$(echo $CREDS | awk '{print $1}')
export AWS_SECRET_ACCESS_KEY=$(echo $CREDS | awk '{print $2}')
export AWS_SESSION_TOKEN=$(echo $CREDS | awk '{print $3}')

# Your AWS CLI commands here
aws s3 ls

403 Access Denied errors: Verify the trust relationship between accounts includes your base account ARN

Expired credentials: Default session duration is 1 hour - request longer duration if needed

MFA requirements: Add --serial-number and --token-code parameters if MFA is enabled

• Always use the principle of least privilege when configuring roles
• Rotate base account credentials regularly
• Consider using AWS SSO for enterprise environments
• Enable CloudTrail logging to monitor role assumptions