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

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.
Local development: aws configure (writes [default]), or set AWS_PROFILE=myprofile when you only use named profiles.

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'}
});

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.
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.
Don't mix SDK v2 and v3 credential setups — configure whichever SDK your code actually imports.

Inspect in DynoTable

If DynoTable lists your tables, credentials resolve — the problem is which source your process reads. Add the same profile under Settings → Profiles, run Test Connection, and compare against aws sts get-caller-identity in the same shell your app uses.

For Local, set endpoint http://localhost:8000 with dummy local/local credentials on the profile. See Connect to AWS and Install. Open tables with ⌘K after connect. Run a test query via the Query Builder to confirm signing works.

Sources

Set credentials in Node.js — AWS SDK for JavaScript v3 (verified 2026-07-13)
AWS SDKs and Tools standardized credential providers (verified 2026-07-13)

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

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