AWS CLI Unable to Locate Credentials? How to Fix It

When aws sts get-caller-identity or any other AWS CLI command fails with Unable to locate credentials, the AWS CLI checked its credential sources but none produced credentials it could use to sign the request. That is different from AccessDenied, which means credentials were present but the call was denied.

The walkthrough uses AWS CLI 2.37.3 on a Linux workstation with isolated credential files so each failure mode is visible without touching production profiles. The same checks apply on macOS, in CI shells, and on EC2 instances — the credential source differs depending on where the command runs.

      aws sts get-caller-identity
                ↓
  CLI walks the credential provider chain
                ↓
┌───────────────┴────────────────┐
│ env vars → profiles → IMDS/…   │
└───────────────┬────────────────┘
                ↓
    valid keys or role session?
                ↓
        ┌──────┴──────┐
        yes            no
        │              │
        ▼              ▼
    API call      Unable to locate
                  credentials

Where to run the commands

• All diagnostic commands run on the workstation, container, or EC2 instance where the failing aws command runs.
• Run aws configure list in the same shell that failed; it shows which settings that CLI process is actually seeing.

Quick Diagnosis

When the error appears, run these five steps in the failing shell before editing files:

1. Run aws configure list.
2. Run aws configure list-profiles.
3. Run env | grep '^AWS_'.
4. Fix the authentication method the environment is supposed to use — local profile, aws login, IAM Identity Center, assumed role, or EC2 instance profile.
5. Verify with aws sts get-caller-identity.

The sections below explain each branch. Start with the TYPE and LOCATION columns from step 1 — they show which provider supplied each value.

What the Error Means

Unable to locate credentials is a client-side error from the AWS CLI credential resolver. The CLI could not sign the request, so the call never reached AWS as an authenticated request and IAM permissions were never evaluated.

Several related messages look similar but mean different things:

Common causes of Unable to locate credentials:

• No ~/.aws/credentials entry and no environment variables
• AWS_PROFILE points at a profile name that does not exist
• AWS_CONFIG_FILE or AWS_SHARED_CREDENTIALS_FILE aim at empty or wrong paths
• A shell script unset credentials before calling aws
• On EC2, no instance profile is attached or IMDS credentials are unreachable

AWS CLI v2.32 and later may append a hint about aws login when no provider succeeds:

aws sts get-caller-identity

aws: [ERROR]: An error occurred (NoCredentials): Unable to locate credentials. You can configure credentials by running "aws login".

That message still means the provider chain returned nothing usable. It does not mean the only fix is aws login — named profiles, environment variables, IAM Identity Center, and EC2 instance roles remain valid paths depending on how the account expects authentication.

A related error appears when the profile name itself is wrong. The CLI returns The config profile (missing-lab-profile) could not be found before it can read keys from a shared credentials file. Fix the profile name first, then recheck for missing keys.

See Where AWS CLI Looks for Credentials

aws configure list shows which profile, keys, and Region the CLI would use for the next command. Run it immediately after the failure — before changing files.

aws configure list

With no credentials configured, aws configure list showed every signing field as <not set>:

NAME       : VALUE                    : TYPE             : LOCATION
profile    : <not set>                : None             : None
access_key : <not set>                : None             : None
secret_key : <not set>                : None             : None
region     : ap-south-1               : env              : ['AWS_REGION', 'AWS_DEFAULT_REGION']

The TYPE and LOCATION columns identify the provider that supplied each value. When access_key shows <not set>, the chain found no signing material.

List profile names defined in the active credentials and config files:

aws configure list-profiles

glc-cred-lab-works

If AWS_PROFILE is set, the profile row should match a name from that list. When the list is empty or the name is missing, either the credentials file path is wrong or no profiles were created yet.

AWS evaluates several distinct credential sources. The table below maps each source to what aws configure list usually shows — not a full precedence list, but enough to read the output:

Environment credentials can override profile-based values. A profile is not one single credential source — profile configuration can invoke assume role, web identity, IAM Identity Center, or aws login, so read both the profile name and the TYPE column together.

Check the Active Profile

Named profiles split credentials (~/.aws/credentials or AWS_SHARED_CREDENTIALS_FILE) from Region and output settings (~/.aws/config or AWS_CONFIG_FILE). AWS_PROFILE selects the active named profile. If no profile is selected, the CLI normally falls back to [default].

When AWS_PROFILE points at a missing profile, the CLI fails before loading keys:

export AWS_PROFILE=missing-lab-profile
aws sts get-caller-identity

aws: [ERROR]: The config profile (missing-lab-profile) could not be found

The same profile name should appear on the profile row when the list command runs in that shell:

aws configure list

profile    : missing-lab-profile      : env              : ['AWS_PROFILE']

Fix the profile name to one that exists:

export AWS_PROFILE=glc-cred-lab-works
aws configure list

NAME       : VALUE                    : TYPE             : LOCATION
profile    : glc-cred-lab-works       : env              : ['AWS_PROFILE']
access_key : ****************MPLE     : shared-credentials-file :
secret_key : ****************KEY      : shared-credentials-file :
region     : ap-south-1               : env              : ['AWS_REGION', 'AWS_DEFAULT_REGION']

Botocore also recognizes AWS_DEFAULT_PROFILE, but AWS CLI documentation primarily teaches AWS_PROFILE. For a persistent default in an interactive shell, export AWS_PROFILE in ~/.bashrc or pass --profile on each command. In CI, inject the correct profile name or credentials for that job only.

Check Environment Variables

Environment variables override shared credential files. When AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY are set, aws configure list marks them as env even if profiles exist on disk.

unset AWS_PROFILE
export AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
aws configure list

NAME       : VALUE                    : TYPE             : LOCATION
profile    : <not set>                : None             : None
access_key : ****************MPLE     : env              :
secret_key : ****************KEY      : env              :
region     : ap-south-1               : env              : ['AWS_REGION', 'AWS_DEFAULT_REGION']

With valid keys, the same shell can call STS without a named profile:

aws sts get-caller-identity

{
    "UserId": "AIDAU7QAIUYJEXAMPLE",
    "Account": "123456789012",
    "Arn": "arn:aws:iam::123456789012:user/glc-cred-lab-user"
}

Check which AWS_* variables are set in the failing shell:

env | grep '^AWS_'

AWS_DEFAULT_REGION=ap-south-1
AWS_REGION=ap-south-1
AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
AWS_SECRET_ACCESS_KEY=***
AWS_SHARED_CREDENTIALS_FILE=~/.aws/credentials
AWS_CONFIG_FILE=~/.aws/config

Common mistakes:

• Stale or partial credential environment variables — a non-empty AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY pair overrides file-based credentials, and incomplete temporary credentials can produce separate errors such as Partial credentials found
• AWS_PROFILE still points at the wrong name while keys exist under another profile
• AWS_SESSION_TOKEN is missing for temporary credentials, leaving only partial env data

Unset stale variables to test file-based profiles or instance-role credentials:

unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN AWS_PROFILE
aws configure list

If troubleshooting instance-role credentials on EC2, temporarily unset explicit AWS credential variables so the CLI can fall through to IMDS.

Check Shared Credentials and Config

Default file locations on Linux:

Custom paths override defaults:

AWS_SHARED_CREDENTIALS_FILE replaces the default ~/.aws/credentials path, while AWS_CONFIG_FILE replaces ~/.aws/config. If either variable points to the wrong file, the CLI can miss credentials or profile configuration that still exists under ~/.aws/. Check both variables when the expected profile is missing.

Minimal working pair for a long-lived IAM user key (example only — many accounts disable this path):

# ~/.aws/credentials
[glc-cred-lab-works]
aws_access_key_id = AKIAIOSFODNN7EXAMPLE
aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

# ~/.aws/config
[profile glc-cred-lab-works]
region = ap-south-1
output = json

Then select that profile and confirm STS:

export AWS_PROFILE=glc-cred-lab-works
aws sts get-caller-identity

Prefer short-lived credentials where the account allows them. aws configure can store keys locally, but many teams disable IAM user access keys in favor of IAM Identity Center or role assumption. Use keys only when that is the approved path for the environment.

Use IAM Identity Center or Role Credentials

Many accounts disable long-lived IAM user keys. Supported alternatives:

aws login is not another name for IAM Identity Center. It uses an existing AWS console sign-in to obtain temporary local-development credentials. IAM Identity Center uses an SSO profile and aws sso login.

After SSO or aws login, aws configure list typically shows cached credentials under the configured profile rather than static keys in credentials. When an SSO session expires, the CLI returns an SSO token error — refresh with aws sso login --profile name or aws login as appropriate for that profile type.

Example config skeleton for IAM Identity Center:

[profile my-sso]
sso_start_url = https://my-org.awsapps.com/start
sso_region = ap-south-1
sso_account_id = 123456789012
sso_role_name = ReadOnlyAccess
region = ap-south-1

Do not create a new IAM user access key when the account policy expects SSO or role assumption — fix the profile configuration instead.

EC2 Instance Role Case

On EC2, the CLI obtains temporary credentials from the instance metadata service (IMDS) when an instance profile is attached. No static keys belong in ~/.aws/credentials for the role itself.

         No static keys in ~/.aws/credentials
                     ↓
        Instance profile attached to EC2
                     ↓
           CLI reaches IMDS (IMDSv2)
                     ↓
         Temporary role credentials
                     ↓
   STS ARN = assumed-role/<role>/<instance-id>

Before testing, clear explicit credential overrides so they do not mask the instance profile:

unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN AWS_PROFILE
aws configure list

On a RHEL 10 EC2 instance with an instance profile attached (AWS CLI 2.33.0, IMDSv2 required), the output showed instance-role credentials — not environment variables:

NAME       : VALUE                    : TYPE             : LOCATION
profile    : <not set>                : None             : None
access_key : ****************Z6UW     : iam-role         :
secret_key : ****************Ol+K     : iam-role         :
region     : ap-south-1               : env              : ['AWS_REGION', 'AWS_DEFAULT_REGION']

When the instance-profile credentials are working, STS returns the attached role in the ARN:

aws sts get-caller-identity

{
    "UserId": "AROAEXAMPLEID:i-0123456789abcdef0",
    "Account": "123456789012",
    "Arn": "arn:aws:sts::123456789012:assumed-role/glc-cred-lab-ec2-role/i-0123456789abcdef0"
}

Confirm IMDS exposes the attached role name with an IMDSv2 token:

TOKEN=$(curl -sS -X PUT \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600" \
  http://169.254.169.254/latest/api/token)

curl -sS \
  -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/iam/security-credentials/

glc-cred-lab-ec2-role

That role name should match the instance profile attached in the EC2 console (Security → IAM role). Also check whether metadata lookup is disabled:

env | grep '^AWS_EC2_METADATA_DISABLED='

When AWS_EC2_METADATA_DISABLED is set to a true value, the CLI skips EC2 metadata credential lookup even if an instance profile is attached.

If the same Unable to locate credentials error appears on EC2 after unsetting explicit credential variables:

• Confirm an instance profile is attached in the EC2 console or with aws ec2 describe-instances
• Confirm the IMDSv2 curl test above returns the role name
• Confirm AWS_EC2_METADATA_DISABLED is not blocking metadata lookup
• Confirm AWS_ACCESS_KEY_ID and related variables are unset so the CLI can fall through to IMDS

Verify with STS

After any fix, confirm the active identity before running destructive commands:

aws sts get-caller-identity

{
    "UserId": "AIDAU7QAIUYJEXAMPLE",
    "Account": "123456789012",
    "Arn": "arn:aws:iam::123456789012:user/glc-cred-lab-user"
}

Pair with aws configure list so the account and profile match expectations. If the account is wrong, recheck AWS_PROFILE and environment overrides.

When credentials work but API calls fail with AccessDenied, the signing path is fine — switch to permission troubleshooting such as AccessDenied despite AdministratorAccess.

Summary

Unable to locate credentials means the AWS CLI found no usable signing material, not that IAM denied the call. The failure happens inside the credential provider chain before AWS evaluates permissions, which is why the error differs from AccessDenied even though both block API calls.

Start with aws configure list in the same shell that failed. The TYPE and LOCATION columns show whether environment variables, a named profile, shared files, or instance metadata supplied each value. When access_key is <not set>, check the source shown by aws configure list, then work backward through overrides such as environment variables and profiles.

On EC2, attach an instance profile and confirm IMDSv2 returns the role name before creating IAM user keys. Many accounts expect IAM Identity Center, aws login, or role assumption instead of static keys in ~/.aws/credentials. After any change, verify with aws sts get-caller-identity and confirm the account and ARN match the identity intended for that shell.

References

• Configuration and credential file settings
• Configuring settings for the AWS CLI
• AWS CLI credential provider chain
• AWS CLI aws login command
• IAM Identity Center and the AWS CLI
• Using an IAM role on Amazon EC2 instances