Cannot do operations on a non-existent table (DynamoDB Local)

TL;DR — これは DynamoDB Local による ResourceNotFoundException の表現であり、罠は「non-existent（存在しない）」が このインスタンスが現在のアクセスキー + リージョン向けに開いたデータベースファイル にスコープされている点です。-sharedDb を使わないと、Local は認証情報/リージョンの組み合わせごとに 別々の テーブルセットを保持します。そのため、CLI で作成したテーブルがアプリからは見えないことがあります。Local を -sharedDb で実行する（またはどこでも同一のダミー認証情報 + リージョンを固定する）ようにし、-inMemory は再起動のたびに空で始まることを忘れないでください。

意味

ResourceNotFoundException: Cannot do operations on a non-existent table

リクエストは実行中の DynamoDB Local に到達し、テーブルを探しましたが見つかりませんでした。そのリクエストのアイデンティティ向けに使用しているデータベースの中で です。本物の AWS は同じ失敗を別の言い回し（Requested resource not found）で表現するため、この正確なメッセージはエミュレータと通信している強いヒントです。

発生する理由

• 認証情報/リージョンの分裂（典型例）。 -sharedDb を使わないと、DynamoDB Local は各リクエストのアクセスキー ID とリージョンにちなんでデータベースファイルに名前を付けます。CLI（キー local、リージョン us-east-1 の --profile）とアプリ（キー fake、リージョン local）は、したがって 2つの異なるテーブルセット を見ることになり、それぞれが「自分用に」テーブルを作成しています。
• -inMemory + 再起動 — インメモリモードはディスクに何も保持しません。再起動のたびに空のデータベースになります。
• ボリュームなしの新しいコンテナ — docker run amazon/dynamodb-local は空で始まります。-dbPath ストレージをマウントしていない限り、前のコンテナのテーブルは消えます。
• テーブルが本当に作成されていなかった — セットアップスクリプトが実行されなかった、または別のポート/インスタンスに対して作成した。
• 同じコードが本物の AWS と Local を指している — テーブルはクラウドに存在するがエミュレータには存在しない（またはその逆）。

修正方法

1. この ID が見ているものを確認します — アプリが使う認証情報/リージョン/エンドポイントとまったく同じでテーブルを一覧表示します:

   AWS_ACCESS_KEY_ID=local AWS_SECRET_ACCESS_KEY=local \
   aws dynamodb list-tables --endpoint-url http://localhost:8000 --region us-east-1

   ここでテーブルが見つからないのに「どこかに」存在するなら、それはスコープの問題です。

2. Local を -sharedDb で実行 し、認証情報/リージョンに関わらずすべてのクライアントが1つのデータベースを共有するようにします:

   java -Djava.library.path=./DynamoDBLocal_lib -jar DynamoDBLocal.jar -sharedDb
   # docker: docker run -p 8000:8000 amazon/dynamodb-local -jar DynamoDBLocal.jar -sharedDb

3. または、どこでも1つの ID を固定します — CLI プロファイル、SDK クライアント設定、テストセットアップで同じダミーの accessKeyId、secretAccessKey、region を使います。

4. 再起動をまたいで永続化します — -inMemory を外し、-dbPath を設定し、（Docker では）ボリュームとしてマウントします。

5. セットアップでテーブルを作成します — テストでは、新しいインスタンスが不意打ちにならないよう、スイートのブートストラップでテーブルを作成（して待機）します。

スコープの問題は、推論するよりも 見る 方がはるかに簡単です。DynoTable デスクトップアプリ は DynamoDB Local に接続し、エンドポイント + 認証情報の組み合わせがどのテーブルを見えるかを正確に表示するため、分裂が一目で見えます。シードデータを準備していますか？DynamoDB JSON コンバーター はプレーンな JSON を型付きアイテムに変換します。

FAQ

DynamoDB Local で今作ったばかりのテーブルが存在しないと言われるのはなぜですか？ -sharedDb を使わないと、DynamoDB Local はアクセスキー ID とリージョンごとに別々のデータベースファイルを保持します。そのため、CLI で作成したテーブルは、認証情報やリージョンが異なるとアプリからは見えないことがあります。Local を -sharedDb で実行するか、どこでも同一のダミー認証情報とリージョンを固定してください。

再起動後に DynamoDB Local のテーブルが消えたのはなぜですか？ -inMemory モードではディスクに何も保持されないため、再起動のたびに空のデータベースになります。マウントされたボリュームのない新しい Docker コンテナも空で始まります。-inMemory を外し、-dbPath を設定し、ボリュームとしてマウントしてテーブルを永続化してください。

関連するエラー

• ResourceNotFoundException — 本物の AWS 版（誤ったリージョン/アカウント/テーブル名）。
• Could not connect to DynamoDB Local (ECONNREFUSED)
• DynamoDB Local port 8000 in use
• Learn: Running DynamoDB Local · Connect to Local & LocalStack

References

• DynamoDB local usage notes — AWS DynamoDB Developer Guide (per-credential/Region myaccesskeyid_region.db files, -sharedDb → shared-local-instance.db, -inMemory keeps nothing on disk)
• Deploying DynamoDB locally on your computer — AWS DynamoDB Developer Guide (Docker Compose -sharedDb -dbPath ./data + volume pattern, dummy credentials)
• amazon/dynamodb-local — Docker Hub (official image; fresh containers start empty without a mounted volume)

最終検証日 2026-07-13、上記にリンクした公式 AWS ドキュメントに照らして確認しました。