Debug Which AWS Identity You Are Using

aws sts get-caller-identity is the first command I run when an AWS CLI call mysteriously fails with "access denied". It tells you exactly which IAM identity the CLI is authenticated as. The answer is almost always different from what you assumed.

Tested on AWS CLI v2.17.

When to Use This

• Debugging "access denied" errors in CI/CD or local dev
• Confirming which profile is active before running a destructive command
• Verifying that an aws sts assume-role actually swapped your identity
• Sanity-checking that GitHub Actions OIDC federation is using the right role

Don't use this when you need a list of permissions (use aws iam list-attached-user-policies for that — get-caller-identity only tells you who you are, not what you can do).

Code

# The bare minimum: who am I?
aws sts get-caller-identity
 
# With a specific profile
aws sts get-caller-identity --profile prod
 
# Pretty-printed account number only
aws sts get-caller-identity --query 'Account' --output text
 
# Full identity table
aws sts get-caller-identity --output table

The --query flag uses JMESPath to extract just the field you need — handy in shell scripts where you want to verify the account number before running a destructive command.

Usage

A safety check before deploying to a production AWS account:

#!/usr/bin/env bash
set -euo pipefail
 
EXPECTED_ACCOUNT="123456789012"
 
ACTUAL=$(aws sts get-caller-identity --query 'Account' --output text)
 
if [ "$ACTUAL" != "$EXPECTED_ACCOUNT" ]; then
  echo "✗ Wrong AWS account. Expected $EXPECTED_ACCOUNT, got $ACTUAL"
  echo "  Check your AWS_PROFILE or run: aws configure list"
  exit 1
fi
 
echo "✓ Authenticated to production account $ACTUAL"
# ... continue with deploy ...

This catches the classic "I thought I was on staging" mistake before it costs you a production incident.

Caveats

• aws configure list is the companion command. It shows the resolution chain — which env var, profile, or credentials file is winning. Use both together when debugging.
• get-caller-identity is one of the few API calls that requires no IAM permission. It always works, even for an unauthenticated user (returns an error). That makes it the safest debugging tool.
• Assumed roles show up as arn:aws:sts::ACCOUNT:assumed-role/RoleName/SessionName, not as the underlying IAM user. If you assumed a role, expect to see this format.
• OIDC federation from GitHub Actions shows up with a session name matching your workflow run ID. Useful for tracing which workflow ran which command.

Related Snippets & Reading

• Assume an IAM Role from the CLI(coming soon) — for cross-account workflows
• Authenticate Docker with ECR(coming soon) — another common auth pattern
• AWS STS get-caller-identity reference — official docs