Could not load credentials from any providers

TL;DR — The AWS SDK for JavaScript v3 walked its whole default credential chain — environment variables, SSO, shared config/credentials profiles, web identity, and the container/instance metadata endpoints — and none of them produced credentials. Give the chain a source it can find (env vars, aws configure, an attached role), or pass credentials to the client explicitly — which for DynamoDB Local should be dummy values anyway.

What it means

CredentialsProviderError: Could not load credentials from any providers

Every DynamoDB request must be SigV4-signed, so before the first call the SDK resolves credentials through its provider chain. This error is the chain's "nothing found" result — it fires before any network call to DynamoDB, and it's the JS v3 equivalent of boto3's Unable to locate credentials. It is not a permissions problem (that would be AccessDeniedException) — there's no identity at all.

Why it happens

• No credentials configured anywhere — no AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY in the environment, no ~/.aws/credentials, no role.
• The [default] profile doesn't exist — you only have named profiles, but AWS_PROFILE isn't set, so the chain looks for [default] and finds nothing.
• The process doesn't see your shell's env — a service manager, cron job, container, or IDE launch that doesn't inherit the variables you exported.
• No role attached in the runtime — an ECS task, EC2 instance, or Lambda without the expected IAM role, so the metadata providers return nothing.
• Intermittent under load: IMDS throttling — high-concurrency workloads hammering the EC2 instance metadata service can fail credential fetches sporadically (a known cause of this error appearing "randomly").
• Browser code without an identity source — frontend calls need Cognito Identity Pool (or similar) credentials; there is no ambient chain in a browser.

How to fix it

1. Pick one credential source and verify it end-to-end. Quickest check: aws sts get-caller-identity in the same environment (same user, same container) that runs your code.

2. Local development: aws configure (writes [default]), or set AWS_PROFILE=myprofile when you only use named profiles.

3. DynamoDB Local / LocalStack: don't rely on the chain — pass explicit dummy credentials with the endpoint:

   import {DynamoDBClient} from '@aws-sdk/client-dynamodb';
   
   const client = new DynamoDBClient({
     region: 'local',
     endpoint: 'http://localhost:8000',
     credentials: {accessKeyId: 'local', secretAccessKey: 'local'}
   });

4. In AWS runtimes, attach the role — an instance profile on EC2, a task role on ECS/Fargate, the execution role on Lambda — instead of shipping keys.

5. Under high concurrency on EC2, create the client once (module scope) so credentials are resolved and cached rather than re-fetched per request; SDK retries plus a shared client absorb IMDS hiccups.

6. Don't mix SDK v2 and v3 credential setups — configure whichever SDK your code actually imports.

Once credentials resolve, browsing the data is the fastest way to confirm the whole pipeline — the DynoTable desktop app connects with your AWS profiles (and DynamoDB Local) and shows your tables immediately. Composing the first query? Start with the DynamoDB Expression Builder.

Related errors

• Unable to locate credentials (boto3) — the same failure in Python.
• The security token included in the request is invalid — credentials found, but rejected.
• Missing region in config
• Learn: Running DynamoDB Local

References

• Set credentials in Node.js — AWS SDK for JavaScript v3 Developer Guide (the default credential provider chain)
• AWS SDKs and Tools standardized credential providers — AWS SDKs and Tools Reference Guide
• AWS Signature Version 4 for API requests — IAM User Guide (why every request needs signed credentials)

Last verified 2026-07-13 against the official AWS documentation linked above.