DynamoDB AccessDeniedException — "not authorized to perform dynamodb:..."

TL;DR — Dein IAM-Benutzer bzw. deine Rolle hat keine Berechtigung für die DynamoDB-Aktion auf dieser Ressource. Die Meldung nennt die exakte dynamodb:-Aktion und den ARN — nimm diese Aktion für diesen Ressourcen-ARN in die IAM-Policy der Identität auf (und prüfe auf ein Deny oder eine Bedingung, die den Zugriff blockiert).

Was es bedeutet

AccessDeniedException: User: arn:aws:iam::123456789012:user/app is not authorized to
perform: dynamodb:Query on resource: arn:aws:dynamodb:us-east-1:123456789012:table/Orders
because no identity-based policy allows the dynamodb:Query action

IAM hat den Aufruf verweigert. Die Meldung ist eine Checkliste: Sie nennt den Principal, die Aktion und die Ressource — alle drei müssen erlaubt sein, ohne ein explizites Deny. Der abschließende Satz nennt den Policy-Typ, der den Zugriff verweigert hat (identity-based policy, SCP, permissions boundary, session policy, …). DynamoDB gibt sie mit HTTP-Status 400 zurück, und sie ist nicht wiederholbar — dieselbe Anfrage schlägt fehl, bis sich die Policy (oder die Identität) ändert.

Warum es passiert

Die Aktion ist nicht erlaubt — die Policy gewährt dynamodb:GetItem, aber du hast Query aufgerufen, oder sie fehlt ganz.
Der Ressourcen-ARN passt nicht — die Policy erlaubt table/Orders, aber du fragst einen Index ab (braucht table/Orders/index/*) oder eine andere Tabelle.
Ein explizites Deny irgendwo (eine Permission Boundary, eine SCP oder die Policy selbst) überschreibt das Allow.
Eine Policy-Bedingung ist nicht erfüllt (dynamodb:LeadingKeys Fine-Grained Access, Source-IP, MFA).
Falsche Credentials — die angenommene Rolle ist nicht die mit Zugriff.

So behebst du es

Gewähre die exakte Aktion, die die Meldung nennt, für den exakten Ressourcen-ARN. Nimm Index-ARNs (.../index/*) auf, wenn du einen GSI/LSI abfragst.
Prüfe auf ein überschreibendes Deny — Permission Boundaries und SCPs schlagen Allows.
Verifiziere Fine-Grained-Bedingungen (dynamodb:LeadingKeys usw.), ob sie wirklich zu deiner Anfrage passen.
Bestätige die Identität mit aws sts get-caller-identity — stelle sicher, dass es der Principal ist, den du meinst.

Beispiel-Policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["dynamodb:Query", "dynamodb:GetItem", "dynamodb:PutItem"],
      "Resource": [
        "arn:aws:dynamodb:us-east-1:123456789012:table/Orders",
        "arn:aws:dynamodb:us-east-1:123456789012:table/Orders/index/*"
      ]
    }
  ]
}

In DynoTable öffnen

DynoTable löst bei jeder Verbindung dasselbe ~/.aws-Profil auf, das auch deine CLI verwendet (Ein AWS-Konto verbinden) — korrigierst du also IAM oder wechselst du das Profil, übernimmt die App das ohne Neustart. Drücke ⌘P, um den Profil-Umschalter zu öffnen und zu bestätigen, welche Identität aktiv ist — der Statuspunkt der Credentials wird rot und zeigt eine Reconnect-Aktion inline an, wenn Tokens mitten in der Sitzung ablaufen.

Wenn deine Policy dynamodb:ListTables verweigert, aber Lesezugriffe auf eine benannte Tabelle erlaubt, kann DynoTable diese Tabelle trotzdem direkt öffnen: ⌘K → Open table by name überspringt den List-Call und geht direkt zu GetItem/Query auf der Tabelle, die du eintippst. Sobald der Zugriff funktioniert, leitet der visuelle Query Builder aus deinen Filter-Pills ab, ob es ein Query oder ein Scan wird — so kannst du belegen, dass die Policy die benötigte Operation erlaubt. Nennt der Fehler einen GSI-/LSI-ARN, gewähre dynamodb:Query auf table/YourTable/index/* — Index-Berechtigungen werden häufig übersehen, wenn die Allows auf Tabellenebene korrekt aussehen.

Quellen

Troubleshoot access denied error messages — IAM User Guide (verified 2026-07-13)
Using IAM policy conditions for fine-grained access control — Amazon DynamoDB Developer Guide (verified 2026-07-13)
Error handling with DynamoDB — Amazon DynamoDB Developer Guide (verified 2026-07-13)