Could not load credentials from any providers

TL;DR — Das AWS SDK for JavaScript v3 ist seine gesamte Default-Credential-Chain durchlaufen — Umgebungsvariablen, SSO, geteilte Config-/Credentials-Profile, Web Identity und die Container-/Instance-Metadata-Endpoints — und keiner davon hat Credentials geliefert. Gib der Chain eine Quelle, die sie finden kann (Env-Variablen, aws configure, eine angehängte Rolle), oder übergib credentials explizit an den Client — was für DynamoDB Local ohnehin Dummy-Werte sein sollten.

Was es bedeutet

CredentialsProviderError: Could not load credentials from any providers

Jede DynamoDB-Anfrage muss SigV4-signiert sein, also löst das SDK vor dem ersten Aufruf Credentials über seine Provider-Chain auf. Dieser Fehler ist das „nichts gefunden"-Ergebnis der Chain — er feuert vor jedem Netzwerkaufruf an DynamoDB und ist das JS-v3-Äquivalent zu boto3s Unable to locate credentials. Es ist kein Berechtigungsproblem (das wäre AccessDeniedException) — es gibt überhaupt keine Identität.

Warum es passiert

• Nirgendwo Credentials konfiguriert — kein AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY in der Umgebung, kein ~/.aws/credentials, keine Rolle.
• Das [default]-Profil existiert nicht — du hast nur benannte Profile, aber AWS_PROFILE ist nicht gesetzt, sodass die Chain nach [default] sucht und nichts findet.
• Der Prozess sieht die Env deiner Shell nicht — ein Service-Manager, Cron-Job, Container oder IDE-Start, der die exportierten Variablen nicht erbt.
• Keine Rolle in der Runtime angehängt — ein ECS-Task, eine EC2-Instanz oder Lambda ohne die erwartete IAM-Rolle, sodass die Metadata-Provider nichts zurückgeben.
• Sporadisch unter Last: IMDS-Throttling — hochparallele Workloads, die den EC2-Instance-Metadata-Service hämmern, können Credential-Fetches sporadisch fehlschlagen lassen (eine bekannte Ursache, dass dieser Fehler „zufällig" auftritt).
• Browser-Code ohne Identitätsquelle — Frontend-Aufrufe brauchen Cognito-Identity-Pool- (oder ähnliche) Credentials; im Browser gibt es keine Umgebungs-Chain.

So behebst du es

1. Wähle eine Credential-Quelle und verifiziere sie durchgängig. Schnellster Check: aws sts get-caller-identity in derselben Umgebung (gleicher User, gleicher Container), die deinen Code ausführt.

2. Lokale Entwicklung: aws configure (schreibt [default]), oder setze AWS_PROFILE=myprofile, wenn du nur benannte Profile nutzt.

3. DynamoDB Local / LocalStack: verlass dich nicht auf die Chain — übergib explizite Dummy-Credentials mit dem 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 hänge die Rolle an — ein Instance-Profile auf EC2, eine Task-Rolle auf ECS/Fargate, die Execution-Rolle auf Lambda — statt Keys auszuliefern.

5. Unter hoher Parallelität auf EC2 erstelle den Client einmal (Modul-Scope), sodass Credentials aufgelöst und gecacht statt pro Anfrage neu geholt werden; SDK-Retries plus ein gemeinsamer Client fangen IMDS-Aussetzer ab.

6. Mische keine SDK-v2- und v3-Credential-Setups — konfiguriere das SDK, das dein Code tatsächlich importiert.

Sobald Credentials aufgelöst sind, ist das Durchsuchen der Daten der schnellste Weg, die gesamte Pipeline zu bestätigen — die DynoTable-Desktop-App verbindet sich mit deinen AWS-Profilen (und DynamoDB Local) und zeigt deine Tabellen sofort. Die erste Query zusammenstellen? Starte mit dem DynamoDB Expression Builder.

Verwandte Fehler

• Unable to locate credentials (boto3) — derselbe Fehler in Python.
• The security token included in the request is invalid — Credentials gefunden, aber abgewiesen.
• 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)

Zuletzt verifiziert am 2026-07-13 gegen die oben verlinkte offizielle AWS-Dokumentation.