Credential should be scoped to a valid region

TL;DR — Signature Version 4 backt in den Credential Scope jedes Requests eine Region ein. Dieser Fehler heißt, dass die Region in diesem Scope nicht zu der Region des Endpunkts passt, den du tatsächlich angesprochen hast — du hast für eine Region signiert und den Request an eine andere geschickt (oder einen ungültigen Regionscode benutzt). Sorg dafür, dass die konfigurierte Region des Clients zum aufgerufenen Endpunkt passt.

Was es bedeutet

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

Jede signierte AWS-Anfrage trägt einen Credential-Scope — einen YYYYMMDD/region/service/aws4_request-String, über den die Signatur berechnet wird (die Region- und Service-Codes müssen kleingeschrieben sein). AWS leitet die erwartete Signatur aus dem Endpoint neu ab, der die Anfrage erhalten hat. Wenn die in deinem Scope eingebettete Region nicht die Region ist, die die Anfrage bedient, schlägt die Verifizierung mit dieser Meldung fehl. Es ist ein HTTP 400, clientseitig und nicht wiederholbar, bis die Region korrigiert ist.

Warum es passiert

Für eine Region signiert, an eine andere gesendet — die konfigurierte region des SDK unterscheidet sich von einem hartkodierten oder überschriebenen endpoint, der auf eine andere Region zeigt.
Ein Custom-Endpoint ohne passende Region — du hast endpoint: https://dynamodb.eu-west-2.amazonaws.com gesetzt, aber die Client-Region bei eu-west-1 gelassen.
Ein ungültiger oder leerer Region-String — ein Tippfehler oder eine nicht gesetzte Env-Variable ergibt einen Scope, den AWS nicht als gültig akzeptieren kann.
Ein Proxy oder Gateway, der die Anfrage an einen anderen regionalen Endpoint weiterleitet als den, für den sie signiert wurde.

So behebst du es

Bringe die Client-Region mit dem Endpoint in Einklang. Wenn du auf dynamodb.<region>.amazonaws.com zeigst, setze die region des Clients auf dasselbe <region>.
Bevorzuge, nur die Region zu setzen und lass das SDK den Endpoint bauen — lass manuelle endpoint-Überschreibungen weg, es sei denn, du brauchst wirklich eine (z. B. DynamoDB Local).
Verifiziere, dass der Region-Code gültig (us-east-1, eu-west-2, …) und tatsächlich gesetzt ist — prüfe AWS_REGION/AWS_DEFAULT_REGION und jede Config-Datei.
Für Assumed-Role- oder cross-regionale Setups bestätige, dass die Anfrage mit der Region signiert wird, an die du sie senden willst, nicht mit einem anderswo geerbten Default.

Für DynamoDB Local zeige den Endpoint auf http://localhost:8000 und gib dem Client eine beliebige konsistente Region — die Region muss nur zu dem passen, womit der Client signiert.

Zuerst in DynoTable prüfen

DynoTable signiert jede Anfrage with the region stored on the active profile. Einstellungen → Profile zeigt Region und optionalen Custom Endpoint in einem Formular — change them together, then Verbindung testen. Das entfernt den klassischen SDK-Failure-Mode, in dem endpoint auf eu-west-2 während region stays eu-west-1.

Drücke ⌘P, um confirm which profile (and therefore which credential scope) is live bevor du debug application code. Für Local, behalte Endpoint http://localhost:8000 und jede passende Region auf demselben Profil. Sobald das Profil verbunden ist, use the Query Builder um zu beweisen, dass Reads mit diesem Scope funktionieren.

Quellen

Troubleshoot Signature Version 4 signing (verifiziert 2026-07-13)
Create a signed AWS API request (verifiziert 2026-07-13)

Referenzen

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