Introduction

The AWS CLI equivalent of whoami is aws sts get-caller-identity. It tells you which AWS principal the CLI is currently using and is the standard first check when you are debugging profiles, assumed roles, or environment-variable credentials. If the command succeeds, your CLI has usable credentials for that identity path.

The Command You Want

Run:

aws sts get-caller-identity

Typical output looks like this:

1{
2  "UserId": "AIDAXXXXXXXXXXXXX",
3  "Account": "123456789012",
4  "Arn": "arn:aws:iam::123456789012:user/example-user"
5}

The key fields are:

• 'Account: the AWS account id'
• 'Arn: the full identity, often an IAM user or assumed-role ARN'
• 'UserId: the internal identifier for the caller'

That is usually enough to confirm whether you are using the expected account and role.

Why This Is Better Than Guessing From Config Files

AWS credentials can come from several places:

• environment variables
• named CLI profiles
• SSO sessions
• instance or container metadata credentials
• assumed-role chains

Reading ~/.aws/config or ~/.aws/credentials tells you what might be configured, not what the CLI is actually using at this moment. get-caller-identity answers the real question by asking AWS directly.

Using a Specific Profile

If you want to verify a named profile, pass it explicitly:

aws sts get-caller-identity --profile dev

This is especially useful when you have several profiles and want to confirm that shell state or exported environment variables are not overriding your expectation.

A Concise "Who Am I" Output

You can make the result easier to scan with a query:

aws sts get-caller-identity --query 'Arn' --output text

Or print account and ARN together:

aws sts get-caller-identity --query '[Account, Arn]' --output text

These are convenient in scripts, shell prompts, or quick environment checks.

What Failure Looks Like

If credentials are missing, expired, or invalid, the command fails instead of returning identity data. Common failure cases include:

• no credentials configured
• expired temporary session
• wrong region-independent auth setup for SSO or role assumption
• environment variables pointing at stale credentials

That is why this command is such a strong diagnostic step: it is both an identity check and a credential-validity check.

Role Assumption and Temporary Credentials

If you are using an assumed role, the ARN usually looks like this pattern:

arn:aws:sts::123456789012:assumed-role/Admin/session-name

That tells you two useful things immediately:

• you are not acting as the base IAM user directly
• the active session name and role path are visible in the ARN

This is often the fastest way to catch a shell session that is pointing at the wrong role.

Where This Fits in Troubleshooting

When an AWS command fails, check identity before anything else:

1. run aws sts get-caller-identity
2. confirm the account and ARN are the ones you expect
3. only then debug service-specific permissions or region issues

This order matters. Many "permission bugs" are actually profile or credential-selection mistakes.

Common Pitfalls

• Looking only at local config files instead of verifying the active caller identity.
• Forgetting --profile when multiple profiles exist on the machine.
• Misreading an assumed-role ARN as if it were an IAM user ARN.
• Assuming valid credentials for one terminal session also apply to another.
• Debugging a service permission issue before confirming you are in the correct account and role.

Summary

• The AWS CLI "whoami" command is aws sts get-caller-identity.
• It shows the active account, ARN, and caller identifier.
• Use --profile when you want to verify a specific configured profile.
• Use --query and --output text for compact shell-friendly output.
• This should be the first credential check in almost any AWS CLI troubleshooting flow.