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

En bref — Ton utilisateur/rôle IAM n'a pas la permission pour l'action DynamoDB sur cette ressource. Le message nomme l'action dynamodb: et l'ARN exacts — ajoute cette action pour cet ARN de ressource à la politique IAM de l'identité (et vérifie qu'aucun Deny ni condition ne la bloque).

Ce que ça signifie

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 a refusé l'appel. Le message est une liste de contrôle : il nomme le principal, l'action et la ressource — les trois doivent être autorisés sans aucun Deny explicite. La clause finale nomme le type de politique qui a refusé l'accès (politique basée sur l'identité, SCP, limite de permissions, politique de session, …). DynamoDB le renvoie avec un statut HTTP 400, et il n'est pas réessayable — la même requête échoue tant que la politique (ou l'identité) ne change pas.

Pourquoi ça arrive

L'action n'est pas autorisée — la politique accorde dynamodb:GetItem mais tu as appelé Query, ou elle manque entièrement.
L'ARN de ressource ne correspond pas — la politique autorise table/Orders mais tu interroges un index (nécessite table/Orders/index/*) ou une autre table.
Un Deny explicite quelque part (une limite de permissions, un SCP ou la politique elle-même) l'emporte sur l'autorisation.
Une condition de politique n'est pas satisfaite (accès affiné dynamodb:LeadingKeys, IP source, MFA).
Mauvais identifiants — le rôle que tu as assumé n'est pas celui qui a l'accès.

Comment le corriger

Accorde l'action exacte nommée par le message, pour l'ARN de ressource exact. Inclus les ARN d'index (.../index/*) quand tu interroges un GSI/LSI.
Cherche un Deny prioritaire — les limites de permissions et les SCP l'emportent sur les autorisations.
Vérifie les conditions affinées (dynamodb:LeadingKeys, etc.) — assure-toi qu'elles correspondent réellement à ta requête.
Confirme l'identité avec aws sts get-caller-identity — assure-toi que c'est bien le principal que tu crois.

Exemple de politique

{
  "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/*"
      ]
    }
  ]
}

Ouvre-le dans DynoTable

DynoTable résout le même profil ~/.aws que ta CLI à chaque connexion (Connecter un compte AWS) : quand tu corriges l'IAM ou changes de profil, l'app le reprend sans redémarrage. Appuie sur ⌘P pour ouvrir le sélecteur de profils et confirmer quelle identité est active — la pastille de statut des identifiants passe au rouge, avec une action Reconnect en ligne, quand les jetons expirent en pleine session.

Si ta politique refuse dynamodb:ListTables mais autorise les lectures sur une table nommée, DynoTable peut quand même ouvrir cette table directement : ⌘K → Open table by name saute l'appel de liste et va droit au GetItem/Query sur la table que tu tapes. Une fois l'accès obtenu, le query builder visuel déduit Query-vs-Scan de tes pastilles de filtre, de quoi prouver que la politique autorise l'opération dont tu as besoin. Si l'erreur nomme un ARN de GSI/LSI, accorde dynamodb:Query sur table/YourTable/index/* — les permissions d'index sont un oubli fréquent quand les autorisations au niveau table ont l'air correctes.

Erreurs liées

The security token is invalid — identifiants incorrects/expirés (vs. identifiants valides sans permission).
Missing region in config
Apprends : Running DynamoDB Local — développe en local, là où les politiques IAM ne s'appliquent pas.

Sources

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