boto3 / botocore 'NoCredentialsError: Unable to locate credentials' (or AWS CLI 'Unable to locate credentials. You can configure credentials by running aws configure'). How do I fix it?

Cause: the AWS SDKs and CLI look for credentials in a fixed order and found none. For boto3 the order is roughly: credentials passed in code, environment variables (AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY / AWS_SESSION_TOKEN), assume-role and IAM Identity Center (SSO) profiles, the shared files ~/.aws/credentials and ~/.aws/config, then container credentials (ECS/EKS) and the EC2 instance metadata service. Common triggers: running as a different user (sudo, a service account, a container) whose home has no ~/.aws, AWS_PROFILE naming a profile that doesn't exist, an SSO session that was never started, a container or CI job with no role attached, or an EC2 instance without an instance profile. How to check: - aws sts get-caller-identity shows which identity (if any) is found. - aws configure list shows where each value comes from (env, shared file, IAM role) and which profile is active. - echo $AWS_PROFILE and check that profile exists in ~/.aws/config. Fix (pick what fits): 1. Local dev with IAM Identity Center (preferred over long-lived keys): aws configure sso, then aws sso login --profile <name>, and set AWS_PROFILE=<name> or pass profile_name to boto3.Session(). 2. Local dev with access keys: aws configure (writes ~/.aws/credentials), or export the three environment variables for the session. 3. On AWS compute, use a role, not keys: attach an instance profile to EC2, a task role to ECS, IAM Roles for Service Accounts or Pod Identity on EKS, an execution role on Lambda. If EC2 still fails, check the instance metadata settings (IMDSv2 hop limit of 2 is needed for containers on the instance). 4. In CI, use the platform's OIDC federation to assume a role (for example aws-actions/configure-aws-credentials on GitHub Actions) instead of storing keys as secrets. 5. In Docker locally, pass credentials explicitly (environment variables, or mount ~/.aws read-only and set AWS_PROFILE); the container doesn't see your host's home directory otherwise. Don't hard-code keys in source or commit ~/.aws files. If keys were ever committed, deactivate them in IAM and create new ones. Verify: aws sts get-caller-identity (or boto3.client('sts').get_caller_identity()) returns the expected account and role. Sources: https://boto3.amazonaws.com/v1/documentation/api/latest/guide/credentials.html https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html https://docs.aws.amazon.com/sdkref/latest/guide/standardized-credentials.html