How to Set Up Cross-Account AWS CLI Access with IAM Identity Center

I used to manage AWS CLI access by rotating access keys regularly and storing them in ~/.aws/credentials, which felt like a security liability every time someone joined the team. Switching to IAM Identity Center SSO eliminated that headache—no long-lived keys, automatic token expiry, and the ability to revoke access instantly through the portal.

Verify Your AWS CLI Version

The AWS CLI v2 is required for SSO support. Verify your version:

aws --version

You should see aws-cli/2.x.x or higher. If you have v1 installed, download and install v2 from the AWS CLI installation guide. Installation takes a few minutes and replaces the old binary.

Note: AWS CLI v1 does not support IAM Identity Center SSO. Always use v2 for this workflow.

Run the Interactive SSO Configuration

The aws configure sso command walks you through setting up a named profile for SSO access:

aws configure sso

You’ll be prompted for:

1. SSO start URL: Your IAM Identity Center Access Portal URL (e.g., https://d-xxxxxxxxxx.awsapps.com/start/)
2. SSO Region: The AWS region where IAM Identity Center is deployed (e.g., us-east-1)
3. SSO Account ID: The AWS account ID you want to access (a dropdown will appear in your browser)
4. SSO Role Name: The permission set name assigned to you in that account (e.g., DeveloperAccess)

A browser window opens automatically, prompting you to sign in with your corporate credentials. After authentication, the CLI detects available accounts and permission sets, and you select the ones you want in this profile. Name the profile something meaningful, like dev or prod.

Inspect the Generated AWS Configuration

The aws configure sso command creates or updates your ~/.aws/config file. Open it to see what was written:

cat ~/.aws/config

You’ll see entries like:

[profile dev]
sso_start_url = https://d-xxxxxxxxxx.awsapps.com/start/
sso_account_id = 123456789012
sso_role_name = DeveloperAccess
sso_region = us-east-1
region = us-east-1
output = json

This configuration tells the AWS CLI where to get temporary credentials. When you use --profile dev, the CLI automatically calls IAM Identity Center, checks your cached token, and uses temporary STS credentials.

Set Up Multiple Profiles for Multiple Accounts

If you need access to multiple AWS accounts (e.g., dev, staging, prod), run aws configure sso again with a different profile name:

aws configure sso --profile prod

Repeat the process for the prod account. Now your ~/.aws/config has both [profile dev] and [profile prod] sections.

Alternatively, you can manually duplicate and edit the config file for speed:

# Copy the dev profile and edit for prod
grep -A 5 "\[profile dev\]" ~/.aws/config | sed 's/dev/prod/g' >> ~/.aws/config

Then update the sso_account_id and sso_role_name values to match the prod account.

Log In and Verify Access

To authenticate and fetch temporary credentials:

aws sso login --profile dev

A browser opens; sign in if you’re not already authenticated. The CLI caches your session token locally. Verify you have access to the correct account:

aws sts get-caller-identity --profile dev

You should see your account ID, user ARN, and a UserId starting with AIDA. This confirms the CLI is using SSO credentials, not stored access keys.

Set a Default Profile and Handle Token Expiry

Typing --profile dev every time is tedious. Set a default profile in your shell:

export AWS_PROFILE=dev

Add this line to your ~/.zshrc or ~/.bashrc to make it permanent. Now aws sts get-caller-identity uses the dev profile by default.

When your SSO token expires (typically after 8 hours of inactivity), you’ll see errors like “Token has expired.” Simply re-run aws sso login --profile dev to refresh the session. The token is cached in ~/.aws/sso/cache/ and automatically removed when it expires.

# Check your cached SSO token expiry
ls -lh ~/.aws/sso/cache/

Is This Safe?

Yes—this is the AWS-recommended approach for human CLI users. No long-lived access keys are stored on disk, eliminating the risk of accidental exposure in git repositories, CI logs, or shared workstations. Tokens are automatically revoked after 8 hours, and revoking the user’s permission set in IAM Identity Center instantly disables CLI access. Your organization’s identity team controls access through a centralized portal instead of distributed credential management.

Key Takeaway

IAM Identity Center SSO for the AWS CLI combines convenience and security. One-time setup, automatic token management, and revocation-on-demand. If you’re managing multiple accounts across a team, this eliminates the credential rotation burden and gives you centralized access control.

Questions? Connect with me on LinkedIn.