The CLI found no credentials in the standard chain. Run one command to see exactly which layer it checks, then configure credentials the right way for your context (profile, env, or instance role).
The credential chain: env vars → ~/.aws/credentials → container/instance role. aws sts get-caller-identity tests the whole chain; 'no identity' = nothing found. Non-interactive shells skip the interactive setup paths.
AWS_CONFIG_FILE/AWS_PROFILE pointing elsewhere, or an aws sso session that expired silently — the profile exists, its credentials don't.
aws sts get-caller-identity 2>&1 | head -3 ; echo $AWS_PROFILE $AWS_ACCESS_KEY_ID
aws configure # or: aws configure --profile work
aws sso login --profile my-sso-profile # expired SSO tokens are the silent cause
# EC2: instance profile role; ECS: task role; CI: OIDC role assumption (aws-actions/configure-aws-credentials) — no long-lived keys anywhere
aws sts get-caller-identity is the universal truth test: it works only when valid credentials exist in the chain. Cron/sudo contexts need explicit env vars or a profile via AWS_PROFILE + config files — they don't inherit your interactive shell.
Those contexts don't source your shell profile or share your session: pass AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY explicitly (or an instance/OIDC role), and set AWS_REGION too.
For local and container dev, acceptable if scoped. For CI, prefer OIDC role assumption; for servers, instance/task roles. Never commit keys or bake them into images.
An opinionated VPC module: per-AZ NAT, explicit dependencies, EKS-ready outputs.
Terraform AWS Foundation — $37 →One-time. Yours to modify. Instant download from the NinjaOps template store.