Attempting to modify a GSI that is being created

TL;DR — グローバルセカンダリインデックスの構築中（IndexStatus = CREATING）は、DynamoDB が競合する構造変更を拒否します。初期のリソース割り当てフェーズでは、新しいインデックスの変更、インデックスまたはテーブルのプロビジョンドスループットの変更、他のインデックスの追加/削除、テーブルの削除ができません。バックフィルが始まると、進行中のインデックスの削除やテーブル/GSI スループットの変更が再びできますが、他のインデックスの追加/削除とテーブルの削除は ACTIVE になるまでブロックされたままです。GSI の変更は 一度に1つずつ 行ってください。UpdateTable ごとに作成または削除を1つだけです。

意味

ValidationException: Attempting to modify a GSI that is being created

データの入ったテーブルに GSI を作成すると バックフィル が発生します。DynamoDB は既存のアイテムをバックグラウンドで新しいインデックスにリプレイします。そのフェーズを通じて、インデックスの IndexStatus は CREATING です。バックフィル中、DynamoDB は構築の一貫性を保つため、インデックスやテーブルへのさらなる構造変更を拒否します。これは HTTP 400 の ValidationException です。インデックスが完了するまで、すぐに再試行しても失敗します。

発生する理由

• インデックス操作の重複 — 最初のインデックスがまだ構築中に、UpdateTable（または IaC の apply）が GSI の変更/削除、あるいは2つ目の追加を試みる。
• CloudFormation/Terraform のバッチ処理 — ツールが1回の更新で複数の GSI 変更を試みる。DynamoDB は UpdateTable ごとに GSI の作成または削除を1つだけ 許可します。
• リソース割り当て中のスループット変更 — 新しいインデックスがまだリソースを割り当てている間（Backfilling: false）は、そのインデックスまたはテーブルのプロビジョンドスループットを変更できません。それらの変更はバックフィルが始まると再び許可されます。
• テーブルを早すぎるタイミングで削除 — バックフィルと競合するティアダウン。

修正方法

1. ACTIVE を待ちます。 DescribeTable をポーリングし、各 GlobalSecondaryIndexes[].IndexStatus を確認します。ACTIVE になってから進めます。

   aws dynamodb describe-table --table-name <Table> \
     --query "Table.GlobalSecondaryIndexes[].{Name:IndexName,Status:IndexStatus}"

   コピーコピーしました
   インデックスの記述には Backfilling ブール値も含まれ（false = リソース割り当て、true = バックフィル中）、OnlineIndexPercentageProgress CloudWatch メトリクスが構築を追跡します。
2. インデックスの変更を順序立てます — UpdateTable ごとに作成/削除を1つだけ。別のインデックスが構築中に新しい GSI を追加しないでください。
3. CloudFormation/Terraform では、GSI の追加を別々のデプロイに分割し、各バックフィルが次の変更の前に完了するようにします。
4. 他のインデックス変更とテーブル削除を延期します — インデックスが ACTIVE になるまで。中止する必要がありますか？バックフィルが始まっていれば、作成中のインデックスを削除して構築をキャンセルできます。

DynoTable で再試行する前に

GSI が CREATING のあいだは、次の UpdateTable を投入する前に、DynoTable でテーブルを開いてテーブル詳細のインデックスステータスを見てください。閲覧しているあいだアプリが DescribeTable を更新し続けます — IndexStatus が ACTIVE に変わると、そのインデックスはクエリパターンのピッカーに現れ、Visual モードやクエリビルダーから Query できるようになります。

DynoTable がまだ CREATING を表示しているあいだに、CloudFormation／Terraform の GSI 変更を 1 回の apply に積み重ねてはいけません。デプロイは順番に行い、apply のあいだは DynoTable を実状を示すステータスパネルとして使ってください。バックフィルが始まったあとに構築を取り消す必要があるなら、IaC／CLI からそのインデックスを削除し、DynoTable のインデックス一覧から消えることを確認します。

出典

• Managing Global Secondary Indexes (2026-07-13 時点で検証)
• UpdateTable — Amazon DynamoDB API Reference (2026-07-13 時点で検証)

関連するエラー

• Local secondary indexes must be specified at table creation — LSI に相当するもの（LSI はそもそも追加できない）。
• ResourceInUseException — 変更可能な状態でないテーブル/インデックスを操作している。
• Requested resource not found / index not found — 準備できていない、または存在しないインデックスを照会している。
• 学習: GSI と LSI · GSI の内部構造

参考資料

• Managing Global Secondary Indexes in DynamoDB — Amazon DynamoDB Developer Guide
• UpdateTable — Amazon DynamoDB API Reference
• Error handling with DynamoDB — Amazon DynamoDB Developer Guide

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