Could not load credentials from any providers

En bref — Le AWS SDK for JavaScript v3 a parcouru toute sa chaîne d'identifiants par défaut — variables d'environnement, SSO, profils shared config/credentials, web identity, et les endpoints de métadonnées conteneur/instance — et aucun n'a produit d'identifiants. Donne à la chaîne une source qu'elle peut trouver (variables d'env, aws configure, un rôle attaché), ou passe credentials au client explicitement — ce qui, pour DynamoDB Local, devrait de toute façon être des valeurs factices.

Ce que ça signifie

CredentialsProviderError: Could not load credentials from any providers

Chaque requête DynamoDB doit être signée en SigV4, donc avant le premier appel le SDK résout les identifiants via sa chaîne de fournisseurs. Cette erreur est le résultat « rien trouvé » de la chaîne — elle se déclenche avant tout appel réseau vers DynamoDB, et c'est l'équivalent JS v3 du Unable to locate credentials de boto3. Ce n'est pas un problème de permissions (ce serait une AccessDeniedException) — il n'y a aucune identité du tout.

Pourquoi ça arrive

Aucun identifiant configuré nulle part — pas de AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY dans l'environnement, pas de ~/.aws/credentials, pas de rôle.
Le profil [default] n'existe pas — tu n'as que des profils nommés, mais AWS_PROFILE n'est pas défini, donc la chaîne cherche [default] et ne trouve rien.
Le processus ne voit pas l'env de ton shell — un gestionnaire de service, un cron, un conteneur ou un lancement d'IDE qui n'hérite pas des variables que tu as exportées.
Aucun rôle attaché dans le runtime — une tâche ECS, une instance EC2 ou une Lambda sans le rôle IAM attendu, donc les fournisseurs de métadonnées ne renvoient rien.
Intermittent sous charge : throttling IMDS — les charges à forte concurrence qui matraquent le service de métadonnées d'instance EC2 peuvent faire échouer sporadiquement la récupération des identifiants (une cause connue de l'apparition « aléatoire » de cette erreur).
Code navigateur sans source d'identité — les appels frontend ont besoin d'identifiants Cognito Identity Pool (ou similaire) ; il n'y a aucune chaîne ambiante dans un navigateur.

Comment corriger

Choisis une source d'identifiants et vérifie-la de bout en bout. Vérification la plus rapide : aws sts get-caller-identity dans le même environnement (même utilisateur, même conteneur) qui exécute ton code.
Développement local : aws configure (écrit [default]), ou définis AWS_PROFILE=myprofile quand tu n'utilises que des profils nommés.

DynamoDB Local / LocalStack : ne t'appuie pas sur la chaîne — passe des identifiants factices explicites avec l'endpoint :

import {DynamoDBClient} from '@aws-sdk/client-dynamodb';

const client = new DynamoDBClient({
  region: 'local',
  endpoint: 'http://localhost:8000',
  credentials: {accessKeyId: 'local', secretAccessKey: 'local'}
});

Dans les runtimes AWS, attache le rôle — un profil d'instance sur EC2, un rôle de tâche sur ECS/Fargate, le rôle d'exécution sur Lambda — au lieu d'expédier des clés.
Sous forte concurrence sur EC2, crée le client une seule fois (portée module) pour que les identifiants soient résolus et mis en cache plutôt que re-récupérés à chaque requête ; les réessais du SDK plus un client partagé absorbent les à-coups d'IMDS.
Ne mélange pas les configurations d'identifiants SDK v2 et v3 — configure le SDK que ton code importe réellement.

Une fois les identifiants résolus, parcourir les données est le moyen le plus rapide de confirmer tout le pipeline — l'application de bureau DynoTable se connecte avec tes profils AWS (et DynamoDB Local) et affiche tes tables immédiatement. Tu composes la première requête ? Commence avec le DynamoDB Expression Builder.

Erreurs liées

Unable to locate credentials (boto3) — le même échec en Python.
The security token included in the request is invalid — identifiants trouvés, mais rejetés.
Missing region in config
Apprends : Running DynamoDB Local

Références

Dernière vérification le 2026-07-13 par rapport à la documentation officielle AWS liée ci-dessus.