Introduction

aws sts get-session-token often fails with a profile because the profile is not backed by long-term IAM user credentials. GetSessionToken is meant to create temporary credentials from long-term credentials, so if the selected profile already uses assumed-role, SSO, or other temporary credentials, the call can fail or behave differently than expected.

GetSessionToken expects base credentials

The command is conceptually for this flow:

• start with long-term IAM user access key and secret key
• optionally include MFA
• ask STS for temporary session credentials

That means a profile like this is the normal fit:

1[dev-user]
2aws_access_key_id = AKIA...
3aws_secret_access_key = SECRET...
4region = us-east-1

And the command looks like:

aws sts get-session-token --profile dev-user

If the profile instead resolves to already temporary credentials, you are stacking temporary-on-temporary in a way this API is not meant for.

Role-based profiles are a common failure source

A profile like this is different:

1[prod-role]
2role_arn = arn:aws:iam::123456789012:role/AdminRole
3source_profile = dev-user
4region = us-east-1

This profile assumes a role. By the time the CLI resolves it, the credentials are already temporary STS credentials. GetSessionToken is not the right next step for that profile.

That is one of the most common reasons people see failures "with profile" even though the same command works with a base IAM user profile.

MFA requirements matter too

If the IAM user requires MFA for GetSessionToken, include:

1aws sts get-session-token \
2  --profile dev-user \
3  --serial-number arn:aws:iam::123456789012:mfa/alice \
4  --token-code 123456

Without the serial number and token code, the request can be denied even when the profile itself is otherwise valid.

Environment variables can override the profile

Another easy trap is forgetting that environment variables can override profile resolution. If variables such as these are set:

• 'AWS_ACCESS_KEY_ID'
• 'AWS_SECRET_ACCESS_KEY'
• 'AWS_SESSION_TOKEN'

then your --profile expectation may not match the actual credentials in use.

When debugging, check:

aws sts get-caller-identity --profile dev-user

That quickly tells you which identity the CLI is actually using.

Distinguish the right STS API for the job

Use:

• 'get-session-token when you start from long-term IAM user credentials and want temporary session credentials'
• 'assume-role when you want credentials for a target IAM role'

Confusing those two APIs is a major source of CLI profile confusion.

If the profile's purpose is role assumption, then assume-role or the built-in profile-based role flow is usually the right mechanism, not get-session-token.

Keep profile design simple

A practical pattern is:

• one base IAM user profile
• optional MFA with get-session-token
• separate role-assumption profiles that chain from the base profile

That keeps the credential story understandable instead of mixing every flow into one profile and one command.

Confirm the active identity before changing config

Running aws sts get-caller-identity with the same profile is often the fastest way to prove whether the CLI is using the credentials you think it is using. That check avoids a lot of blind profile editing.

Common Pitfalls

• Calling get-session-token with a role-based or already temporary-credential profile.
• Forgetting MFA arguments when the IAM policy requires them.
• Letting environment variables override the intended profile.
• Using get-session-token when the real goal is role assumption.
• Debugging the failure without checking aws sts get-caller-identity first.

Summary

• 'get-session-token is intended for long-term IAM user credentials, not already temporary role credentials.'
• Role-based profiles are a common reason the command fails "with profile."
• MFA may be required and must be passed explicitly when needed.
• Environment variables can override the profile you think you are using.
• If the goal is to access a role, assume-role is usually the right STS flow instead.