DynamoDB ResourceNotFoundException

TL;DR — DynamoDB ne trouve pas la table (ou l'index) que tu as nommée dans la région/le compte vers lequel ton client pointe. Vérifie une faute de frappe dans le nom de la table, une mauvaise region, ou des identifiants pour un autre compte. Ce n'est presque jamais que la table a réellement disparu.

Ce que ça signifie

ResourceNotFoundException: Requested resource not found: Table: <table-name> not found

# on DynamoDB Local:
ResourceNotFoundException: Cannot do operations on a non-existent table

La première est ce que renvoie le service AWS réel — elle nomme la table qu'il a cherchée. La seconde est ce que renvoie DynamoDB Local, et la voir est un signe fiable que tu parles à l'émulateur plutôt qu'à AWS. Dans les deux cas, l'opération a ciblé une table ou un index qui n'existe pas du point de vue de ce client — la combinaison nom de table + région AWS + compte (identifiants). Les trois doivent s'aligner. DynamoDB la renvoie avec un statut HTTP 400 et elle n'est pas réessayable — la même requête continue d'échouer tant que tu ne corriges pas le nom, la région ou les identifiants (ou que la table ne finit pas d'être créée : une table trop tôt dans l'état CREATING peut aussi renvoyer cette erreur).

Pourquoi ça arrive

Décalage de région — la table est dans us-east-1 mais le client utilise par défaut us-west-2 (ou aucune région n'est définie, donc le SDK choisit une autre valeur par défaut).
Mauvais nom de table — une faute de frappe, une mauvaise casse (les noms sont sensibles à la casse sur le service web), ou un nom préfixé par l'environnement (prod-Orders vs Orders).
Mauvais compte — les identifiants se résolvent vers un compte AWS différent de celui qui possède la table.
Interrogation d'un index qui n'existe pas ou n'est pas encore ACTIVE (un GSI est encore en backfill) — la référence de l'API mentionne « a nonexistent table or index » dont « status might not be ACTIVE ».
La table a réellement été supprimée, ou tu pointes vers DynamoDB Local, qui démarre vide.

Comment le corriger

Épingle la région explicitement sur le client et confirme qu'elle correspond à l'endroit où vit la table.
Vérifie le nom exact de la table — liste les tables de cette région (aws dynamodb list-tables --region <r>) et copie le nom verbatim.
Confirme que les identifiants se résolvent vers le compte propriétaire (aws sts get-caller-identity).
Vérifie le nom + le statut de l'index si l'appel utilise IndexName (DescribeTable → le GSI doit être ACTIVE).

Exemple

import {DynamoDBClient} from '@aws-sdk/client-dynamodb';

// Pin the region so the client can't silently target the wrong one:
const client = new DynamoDBClient({region: 'us-east-1'});

FAQ

Comment corriger ResourceNotFoundException dans DynamoDB ? Vérifie que le nom de la table, la région AWS et le compte (identifiants) s'alignent tous : épingle la région explicitement sur le client, liste les tables de cette région pour vérifier le nom exact, et confirme que les identifiants se résolvent vers le compte propriétaire avec aws sts get-caller-identity.

ResourceNotFoundException signifie-t-il que ma table a été supprimée ? Rarement. Cela signifie généralement que le client cherche au mauvais endroit — un décalage de région, une faute de frappe ou une mauvaise casse dans le nom de la table, ou des identifiants pour un autre compte. Elle se déclenche aussi quand tu interroges un index qui n'existe pas ou n'est pas encore ACTIVE, ou quand tu pointes vers DynamoDB Local, qui démarre vide.

Workbench DynoTable

DynoTable liste dans sa barre latérale les tables du profil et de la région actifs. S'il manque une table, appuie sur ⌘P pour confirmer le profil et vérifie la région sur l'onglet — une discordance à cet endroit est la cause la plus fréquente de cette erreur dans l'app. ⌘K → Open table by name te laisse taper le nom exact de la table quand ListTables est refusé ou que la liste est filtrée par préfixe. Face à DynamoDB Local, ajoute un profil avec l'endpoint http://localhost:8000 et des identifiants factices cohérents (Se connecter à DynamoDB Local) — Local démarre vide tant que tu n'as pas créé de tables.

Erreurs liées

ResourceInUseException — l'inverse : la table existe déjà.
Missing region in config
The security token is invalid
En savoir plus : Exécuter DynamoDB Local — Local démarre vide ; sache sur quel endpoint tu es.

Sources

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