La credenziale deve avere come ambito una regione valida

TL;DR: la versione 4 della firma inserisce una regione nell'ambito delle credenziali di ciascuna richiesta. Questo errore significa che la regione in tale ambito non corrisponde alla regione dell'endpoint effettivamente raggiunto: hai firmato per una regione e hai inviato la richiesta a un'altra (o hai utilizzato un codice regione non valido). Fai in modo che la regione configurata del client corrisponda all'endpoint che chiami.

Cosa significa

InvalidSignatureException: Credential should be scoped to a valid region, not 'us-west-1'.

Ogni richiesta AWS firmata porta un ambito credenziale: una stringa YYYYMMDD/region/service/aws4_request su cui viene calcolata la firma (i codici della regione e del servizio devono essere in lettere minuscole). AWS deriva nuovamente la firma prevista dall'endpoint che ha ricevuto la richiesta. Se la regione incorporata nel tuo ambito non è la regione che serve la richiesta, la verifica fallisce con questo messaggio. È un HTTP 400, lato client e non riprovabile finché la regione non viene corretta.

Perché succede

  • Firmato per una regione, inviato a un'altra: la "regione" configurata dell'SDK è diversa da un "endpoint" hardcoded o sovrascritto che punta a una regione diversa.
  • Un endpoint personalizzato senza una regione corrispondente: hai impostato "endpoint: https://dynamodb.eu-west-2.amazonaws.com" ma hai lasciato la regione client su "eu-west-1".
  • Una stringa di regione non valida o vuota: un errore di battitura o una variabile ambiente non impostata produce un ambito AWS che non può essere accettato come valido.
  • Un proxy o gateway che inoltra la richiesta a un endpoint regionale diverso da quello per cui è stata firmata.

Come risolverlo

  1. Abbina la regione del client all'endpoint. Se punti a "dynamodb..amazonaws.com", imposta la "regione" del client sullo stesso "".
  2. Preferisci impostare solo la regione e lasciare che sia l'SDK a creare l'endpoint: elimina le sostituzioni manuali dell'endpoint a meno che non ne abbia veramente bisogno (ad esempio DynamoDB Locale).
  3. Verificare che il codice regionale sia valido (us-east-1, eu-west-2, ...) e impostarlo effettivamente: controllare AWS_REGION/AWS_DEFAULT_REGION e qualsiasi file di configurazione.
  4. Per configurazioni con ruolo assunto o tra regioni, conferma che la richiesta è firmata con la regione a cui intendi inviarla e non con un'impostazione predefinita ereditata altrove.

Per DynamoDB Locale, punta l'endpoint su http://localhost:8000 e fornisci al client qualsiasi regione coerente: la regione deve semplicemente corrispondere a ciò con cui firma il client.

Controlla prima in DynoTable

DynoTable firma ogni richiesta con la regione memorizzata sul profilo attivo. Impostazioni → Profili mostra la regione e l'endpoint personalizzato opzionale su un modulo: modificali insieme, quindi Verifica connessione. Ciò rimuove la classica modalità di errore dell'SDK in cui "endpoint" punta a "eu-west-2" mentre "region" rimane "eu-west-1".

Premi ⌘P per confermare quale profilo (e quindi quale ambito delle credenziali) è attivo prima di eseguire il debug del codice dell'applicazione. Per Locale, mantieni l'endpoint "http://localhost:8000" e qualsiasi regione corrispondente sullo stesso profilo. Una volta connesso il profilo, utilizzare il generatore di query per dimostrare che le letture hanno esito positivo con tale ambito.

Fonti

Errori correlati

Riferimenti

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

Lavora con DynamoDB senza la Console

Un client desktop veloce per DynamoDB che esegue il vero SQL che DynamoDB non può — JOINs, GROUP BY, aggregazioni — con modifica visuale e un agente AI sulle tue chiavi Bedrock.

Prova gratuita di 30 giorni, senza carta di credito — poi il piano Free senza limiti di tempo.