DynamoDB はセカンダリインデックスに対応していますか？

対応しています。DynamoDB は 2 種類のセカンダリインデックスをサポートしています。グローバルセカンダリインデックス (GSI) は独自のパーティション/ソートキーとキャパシティを持ちます（デフォルトでテーブルあたり 20 個、結果整合性）。ローカルセカンダリインデックス (LSI) はテーブルのパーティションキーを別のソートキーと共有し、強い整合性をサポートしますが、テーブル作成時に定義しなければなりません。

グローバルセカンダリインデックス (GSI)

テーブルとは独立した、独自の パーティションキーとソートキー。
独自の プロビジョニング済みスループット（またはオンデマンドキャパシティ）。
読み取りは 結果整合性 のみ。
いつでも 追加・削除可能。デフォルトのクォータは テーブルあたり 20 個。

GSI は、テーブルのプライマリキー以外の属性でアイテムを検索するための仕組みです。

ローカルセカンダリインデックス (LSI)

テーブルの パーティションキー を共有し、ソートキーは 別のもの にします。
テーブルの スループット を共有します。
強い整合性 のある読み取りをサポートします。
テーブル作成時 に作る必要があり、後から追加できません。

測定できる 2 つの違い

GSI の読み取りは、強い整合性を要求されたときに黙って格下げしたりしません。失敗します。

ValidationException: Consistent reads are not supported on global secondary indexes
HTTP 400

同じクエリを ConsistentRead: true で LSI に対して実行すると成功し、ConsumedCapacity 1.0 と報告されます。同じアイテムを結果整合性で読んだ場合は 0.5 です。強い整合性は LSI で利用でき、読み取りユニットは 2 倍になります。

2 つ目の違いは書き込み側にあり、これが請求に表れる方です。同一の 920 バイトのアイテムを、GSI の数だけが違う 3 つのテーブルに put すると、こうなります。

0 GSIs   ConsumedCapacity 1   table 1
1 GSI    ConsumedCapacity 2   table 1, gsi1 1
2 GSIs   ConsumedCapacity 3   table 1, gsi1 1, gsi2 1

変更された属性を射影している GSI は、そのひとつひとつが支払う対象の書き込みです。AWS はこの数字が示すルールを明記しています。書き込みコストは "the sum of write capacity units consumed by writing to the base table and those consumed by updating the global secondary indexes" です。その 2 つ目の書き込みを小さく保つ方法が KEYS_ONLY の射影です。

どちらを選ぶか

新しいアクセスパターンと柔軟性のためには GSI に手を伸ばしましょう。同じパーティション内で別のソート順に強い整合性が必要なときは LSI です。

さらに詳しく

GSI と LSI の比較で比べ、インデックスの射影を参照してください。インデックス越しにクエリするには DynoTable をダウンロードしてください。

参考資料

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

エラー文字列と ConsumedCapacity の値は、2026-07-28 に @aws-sdk/client-dynamodb 3.1095.0 経由で DynamoDB Local 3.3.0 に対して捕捉したもので、エンジン自身の出力です。