Credential should be scoped to a valid region

En bref — La Signature Version 4 intègre une région dans le scope d'identifiant de chaque requête. Cette erreur signifie que la région de ce scope ne correspond pas à la région de l'endpoint que tu as réellement atteint — tu as signé pour une région et envoyé la requête à une autre (ou utilisé un code de région invalide). Fais correspondre la région configurée du client à l'endpoint que tu appelles.

Ce que ça signifie

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

Chaque requête AWS signée porte un scope d'identifiant — une chaîne YYYYMMDD/region/service/aws4_request sur laquelle la signature est calculée (les codes de région et de service doivent être en minuscules). AWS re-dérive la signature attendue à partir de l'endpoint qui a reçu la requête. Si la région intégrée dans ton scope n'est pas la région qui sert la requête, la vérification échoue avec ce message. C'est un HTTP 400, côté client, et non réessayable tant que la région n'est pas corrigée.

Pourquoi ça arrive

  • Signé pour une région, envoyé à une autre — la region configurée du SDK diffère d'un endpoint codé en dur ou surchargé pointant vers une région différente.
  • Un endpoint personnalisé sans région correspondante — tu as défini endpoint: https://dynamodb.eu-west-2.amazonaws.com mais laissé la région du client à eu-west-1.
  • Une chaîne de région invalide ou vide — une faute de frappe ou une variable d'env non définie produit un scope qu'AWS ne peut accepter comme valide.
  • Un proxy ou une passerelle qui transfère la requête vers un endpoint régional différent de celui pour lequel elle a été signée.

Comment le corriger

  1. Fais correspondre la région du client à l'endpoint. Si tu pointes vers dynamodb.<region>.amazonaws.com, définis la region du client sur ce même <region>.
  2. Préfère ne définir que la région et laisse le SDK construire l'endpoint — abandonne les overrides manuels d'endpoint sauf si tu en as réellement besoin (p. ex. DynamoDB Local).
  3. Vérifie que le code de région est valide (us-east-1, eu-west-2, …) et réellement défini — vérifie AWS_REGION/AWS_DEFAULT_REGION et tout fichier de config.
  4. Pour les configurations à rôle assumé ou cross-région, confirme que la requête est signée avec la région vers laquelle tu comptes l'envoyer, pas une valeur par défaut héritée ailleurs.

Pour DynamoDB Local, pointe l'endpoint vers http://localhost:8000 et donne au client n'importe quelle région cohérente — la région doit juste correspondre à ce avec quoi le client signe.

Vérifie d’abord dans DynoTable

DynoTable signe chaque requête avec la région stockée sur le profil actif. Settings → Profiles affiche la région et l'endpoint personnalisé optionnel sur un même formulaire — change-les ensemble, puis Test Connection. Ça élimine le grand classique des échecs SDK, où endpoint pointe sur eu-west-2 pendant que region reste à eu-west-1.

Appuie sur ⌘P pour confirmer quel profil (et donc quelle portée d'identifiants) est actif avant de déboguer le code applicatif. Pour Local, garde l'endpoint http://localhost:8000 et une région cohérente sur le même profil. Une fois le profil connecté, sers-toi du query builder pour prouver que les lectures réussissent avec cette portée.

Sources

Erreurs liées

Références

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

Travaille avec DynamoDB sans la Console

Un client de bureau rapide pour DynamoDB qui exécute le vrai SQL que DynamoDB ne peut pas — JOINs, GROUP BY, agrégations — avec édition visuelle et un agent IA sur tes propres clés Bedrock.

Essai gratuit de 30 jours, sans carte bancaire — ensuite la formule Gratuit, sans limite de durée.