Attempting to modify a GSI that is being created

TL;DR — While a global secondary index is building (IndexStatus = CREATING), DynamoDB rejects conflicting structural changes. During the initial resource-allocation phase you can't modify the new index, change the index's or table's provisioned throughput, add or delete other indexes, or delete the table. Once backfilling starts you can delete the in-flight index or change table/GSI throughput again, but adding or deleting other indexes and deleting the table stay blocked until it's ACTIVE. Make GSI changes one at a time — one create or delete per UpdateTable.

What it means

ValidationException: Attempting to modify a GSI that is being created

Creating a GSI on a populated table triggers a backfill — DynamoDB replays existing items into the new index in the background. Throughout that phase the index's IndexStatus is CREATING. During the backfill DynamoDB rejects further structural changes to the index or table so the build stays consistent. It's an HTTP 400 ValidationException; retrying immediately fails until the index finishes.

Why it happens

Overlapping index operations — an UpdateTable (or an IaC apply) tries to modify/delete a GSI, or add a second one, while the first is still building.
CloudFormation/Terraform batching — the tool attempts multiple GSI changes in a single update; DynamoDB allows only one GSI create or delete per UpdateTable.
Throughput change during resource allocation — while the new index is still allocating resources (Backfilling: false), you can't modify the provisioned throughput of that index or of the table; those changes are allowed again once backfilling starts.
Deleting the table too soon — a teardown that races the backfill.

How to fix it

Wait for ACTIVE. Poll DescribeTable and check each GlobalSecondaryIndexes[].IndexStatus; only proceed once it's ACTIVE.
```
aws dynamodb describe-table --table-name <Table> \
  --query "Table.GlobalSecondaryIndexes[].{Name:IndexName,Status:IndexStatus}"
```
The index description also carries a Backfilling boolean (false = resource allocation, true = backfilling), and the OnlineIndexPercentageProgress CloudWatch metric tracks the build.
Sequence index changes — one create/delete per UpdateTable; don't add a new GSI while another is building.
In CloudFormation/Terraform, split GSI additions across separate deploys so each backfill completes before the next change.
Defer other index changes and table deletion until the index is ACTIVE. Need to bail out? Once backfilling has started, you can cancel the build by deleting the index being created.

Before you retry in DynoTable

While a GSI is CREATING, open the table in DynoTable and watch index status under table details before you queue another UpdateTable. The app refreshes DescribeTable as you browse — when IndexStatus flips to ACTIVE, the index appears in the query-pattern picker and you can Query it from Visual mode or the query builder.

Do not stack CloudFormation/Terraform GSI changes in one apply while DynoTable still shows CREATING. Sequence deploys; use DynoTable as the ground-truth status panel between applies. If you need to cancel a build after backfilling starts, delete that index from your IaC/CLI, then confirm it disappears from the DynoTable index list.

Sources

Managing Global Secondary Indexes (verified 2026-07-13)
UpdateTable — Amazon DynamoDB API Reference (verified 2026-07-13)

Local secondary indexes must be specified at table creation — the LSI equivalent (LSIs can't be added at all).
ResourceInUseException — operating on a table/index that isn't in a modifiable state.
Requested resource not found / index not found — querying an index that isn't ready or doesn't exist.
Learn: GSI vs LSI · GSI internals

References

Last verified 2026-07-13 against the official AWS documentation linked above.