DynoTable

DynamoDB LimitExceededException

TL;DR — 一度に多すぎる コントロールプレーン 操作を発行した（またはテーブル/アカウントの制限に達した）のです。アカウント全体で一度に最大 500 のテーブルとインデックスが CREATING/UPDATING/DELETING の状態にできます。テーブル操作を直列化し、ACTIVE を待ち、バックオフで再試行してください。

意味

LimitExceededException: Too many operations for a given subscriber.

これは コントロールプレーン のエラーです。GetItem/PutItem/Query ではなく、CreateTable、UpdateTable、DeleteTable、インデックス作成、復元などの呼び出しから来ます。DynamoDB は、同時実行またはアカウントの制限を超えたと伝えています。これは HTTP 400 で、AWS は リトライ可能 としてリストしています。進行中の操作が完了すると状態は解消されます。

発生する理由

  • 同時実行のテーブル/インデックス操作が多すぎる — CREATING、DELETING、UPDATING 状態のテーブルとインデックスの累積数はアカウント/リージョンあたり 500 を超えられません。（アカウントあたり最大 500 の同時テーブル操作が許可されます — CreateTable、UpdateTable、DeleteTable、UpdateTimeToLive、RestoreTableFromBackup、RestoreTableToPointInTime — そしてセカンダリインデックス付きのテーブル作成時は最大 250 の同時リクエストのみ。）
  • 一括スタックデプロイ — CloudFormation/CDK/Terraform が多数のテーブル（または多数の GSI）を同時に作成またはティアダウンし、同時実行の予算を超える。
  • アカウントのリソースクォータ — アカウント/リージョンあたり 2,500 テーブルのソフトクォータ、または 50 の同時インポートジョブ制限に達する。
  • DynamoDB Streams の誤用 — Limit を 1000 より大きくして GetRecords を呼ぶ、または同じストリームシャードを一度に 2 つより多くのプロセスで読む。
  • 注意: 同じテーブルがまだ UPDATING の間に発行された 2 つ目の UpdateTable は、このエラーではなく ResourceInUseException として現れます。ただし両方とも「まず ACTIVE を待て」を意味します。

修正方法

  1. コントロールプレーン操作を直列化します — テーブル（と各 GSI）が ACTIVE になるのを待ってから、それへの次の変更を発行します。DescribeTable をポーリングし、TableStatus === 'ACTIVE' でゲートします。
  2. 指数バックオフで再試行します — 制限は一時的です。バックオフした再試行は、進行中の操作が排出されると通常成功します。
  3. 一括デプロイをスロットルします — 大きなスタックを分割して数百のテーブル/GSI を一度に作成しないようにするか、明示的な DependsOn の順序を追加してすべてが同時に発火しないようにします。
  4. サービスクォータを確認します — アカウントあたりのテーブル数の制限に近い場合は、永遠に再試行するのではなく Service Quotas でクォータの引き上げを要求します。
  5. GSI を一度に1つずつ追加します — UpdateTable 操作ごとにグローバルセカンダリインデックスを1つだけ作成または削除できるため、インデックスの変更を直列化し、各バックフィルを待ちます。

よくある質問

DynamoDB で LimitExceededException を修正するには？ コントロールプレーン操作（CreateTable/UpdateTable/DeleteTable/インデックス変更）を並列で発行するのをやめます。各テーブルとインデックスが次の変更の前に ACTIVE に達するのを待ち、CREATING/UPDATING/DELETING のテーブル数をアカウントの上限未満に保ち、指数バックオフで再試行します。

LimitExceededException はスロットリングエラーですか？ これはコントロールプレーンの同時実行/制限エラーであり、データプレーンのスロットリングではありません。データプレーンのスロットリングは代わりに ProvisionedThroughputExceededException、ThrottlingException、または RequestLimitExceeded として現れます。

DynoTable を Local に向ける

DynoTable はデータプレーンのクライアントです — GetItem、Query、Scan は、このエラーが 守っているコントロールプレーンの同時実行の枠を消費しません。デプロイスクリプトがテーブル作成中に LimitExceededException に当たったら、IaC がリトライしているあいだ、DynoTable ですでに ACTIVE に なったテーブルを閲覧し、テーブル設定 でスキーマを検証しましょう。ローカルのスタックでは DynamoDB Local を -sharedDb で動かし、Local のプロファイル経由で接続すれば （DynamoDB Local を動かす）、AWS 側ですべての GSI が完了するのを待たずに 途中まで進んだデプロイを確認できます。 シングルテーブル設計プランナーは、混み合ったアカウントで 次の CreateTable を撃つ前に、テーブルの形を下書きするのに役立ちます。

関連するエラー

出典

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

Console なしで DynamoDB を扱う

DynamoDB では実行できない本物の SQL（JOINs、GROUP BY、集計）を実行する高速な DynamoDB デスクトップクライアント。ビジュアル編集と、あなた自身の Bedrock キーで動く AI エージェントを備えています。

ダウンロード料金を見る

30日間無料トライアル、クレジットカード不要 — その後は期限のない Free プラン。