Could not load credentials from any providers

In breve — L'AWS SDK for JavaScript v3 ha percorso la sua intera catena di credenziali di default — variabili d'ambiente, SSO, profili di config/credenziali condivisi, web identity e gli endpoint di metadati del container/istanza — e nessuno di essi ha prodotto credenziali. Dai alla catena una fonte che possa trovare (variabili d'ambiente, aws configure, un ruolo collegato), oppure passa credentials al client esplicitamente — che per DynamoDB Local dovrebbero comunque essere valori fittizi.

Cosa significa

CredentialsProviderError: Could not load credentials from any providers

Ogni richiesta DynamoDB deve essere firmata con SigV4, quindi prima della prima chiamata l'SDK risolve le credenziali tramite la sua catena di provider. Questo errore è il risultato "niente trovato" della catena — scatta prima di qualsiasi chiamata di rete a DynamoDB, ed è l'equivalente JS v3 di Unable to locate credentials di boto3. Non è un problema di permessi (quello sarebbe AccessDeniedException) — non c'è alcuna identità.

Perché accade

Nessuna credenziale configurata da nessuna parte — nessun AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY nell'ambiente, nessun ~/.aws/credentials, nessun ruolo.
Il profilo [default] non esiste — hai solo profili con nome, ma AWS_PROFILE non è impostato, quindi la catena cerca [default] e non trova nulla.
Il processo non vede l'ambiente della tua shell — un service manager, un cron job, un container o un avvio da IDE che non eredita le variabili che hai esportato.
Nessun ruolo collegato nel runtime — un task ECS, un'istanza EC2 o una Lambda senza il ruolo IAM previsto, quindi i provider di metadati non restituiscono nulla.
Intermittente sotto carico: throttling di IMDS — carichi ad alta concorrenza che martellano il servizio di metadati dell'istanza EC2 possono far fallire sporadicamente il recupero delle credenziali (una causa nota della comparsa "casuale" di questo errore).
Codice browser senza una fonte di identità — le chiamate frontend necessitano di credenziali da un Cognito Identity Pool (o simile); in un browser non esiste alcuna catena ambientale.

Come correggerlo

Scegli una fonte di credenziali e verificala end-to-end. Verifica più rapida: aws sts get-caller-identity nello stesso ambiente (stesso utente, stesso container) che esegue il tuo codice.
Sviluppo locale: aws configure (scrive [default]), oppure imposta AWS_PROFILE=myprofile quando usi solo profili con nome.

DynamoDB Local / LocalStack: non affidarti alla catena — passa credenziali fittizie esplicite con l'endpoint:

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

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

Nei runtime AWS, collega il ruolo — un instance profile su EC2, un task role su ECS/Fargate, l'execution role su Lambda — invece di spedire chiavi.
Sotto alta concorrenza su EC2, crea il client una sola volta (a livello di modulo) così le credenziali vengono risolte e memorizzate in cache invece di essere recuperate a ogni richiesta; i retry dell'SDK più un client condiviso assorbono gli intoppi di IMDS.
Non mescolare i setup di credenziali dell'SDK v2 e v3 — configura l'SDK che il tuo codice effettivamente importa.

Una volta risolte le credenziali, sfogliare i dati è il modo più rapido per confermare l'intera pipeline — l'app desktop DynoTable si connette con i tuoi profili AWS (e DynamoDB Local) e mostra subito le tue tabelle. Stai componendo la prima query? Inizia dal DynamoDB Expression Builder.

Errori correlati

Unable to locate credentials (boto3) — lo stesso fallimento in Python.
The security token included in the request is invalid — credenziali trovate, ma rifiutate.
Missing region in config
Impara: Running DynamoDB Local

References

Ultima verifica 2026-07-13 rispetto alla documentazione ufficiale AWS collegata sopra.