DynamoDB ReplicaNotFoundException

TL;DR — The region replica you're trying to update or remove isn't part of this global table. Usually a wrong region name, a replica that was already removed, or a call that races another in-flight replica update. Confirm the current replicas with DescribeTable, then target one that exists.

What it means

ReplicaNotFoundException: The specified replica is no longer part of the global table.

Global-tables operations (UpdateGlobalTable, or UpdateTable with a ReplicaUpdates/Delete) address a replica by its AWS region. This HTTP 400 means the region you named isn't currently a replica of the global table. It's client-side and not retryable until you target a real replica.

Why it happens

Wrong region code — us-east-2 when the replica is in us-east-1, or a region that was never added.
Replica already removed — a delete against a region that a previous update already dropped from the table.
Overlapping replica changes — UpdateTable can't run while the table is still UPDATING from a previous change, and AWS recommends issuing a separate request for each replica add/remove; racing automation can target a replica another job already removed.
Confusing the primary with a replica — operating on a region that hosts no replica of this table.
Version confusion — mixing the legacy Version 2017.11.29 (GlobalTable) and current 2019.11.21 (replica-on-table) APIs.

How to fix it

List the current replicas and their status:

aws dynamodb describe-table --table-name <Table> \
  --query "Table.Replicas[].{Region:RegionName,Status:ReplicaStatus}"

Target a region that's actually in the list — copy the region code exactly.
Change one replica at a time. Wait for the table to return to ACTIVE (and the previous add/remove to finish) before the next update.
Removing a replica that's already gone? There's nothing to do — treat the ReplicaNotFoundException as already-satisfied for a delete.
Use the current (2019.11.21) API — manage replicas via UpdateTable ReplicaUpdates, not the legacy global-table API.

Managing tables across regions? The DynoTable desktop app shows each table's replicas and their status, so you can act on a region that's genuinely part of the global table.

Check first in DynoTable

Open the table in DynoTable and check the table stats / replica list for the regions that actually exist before you run UpdateTable ReplicaUpdates. Switch profiles with ⌘P so you are looking at the account that owns the global table. When a replica region is gone, DynoTable simply omits it — there is no stale console card to click.

Cross-check the region code against the live list, then re-issue the control-plane change from IaC or the CLI. For day-to-day reads across replicas, keep one DynoTable profile per region and switch with ⌘1–⌘9 instead of guessing ARNs. The query builder stays on the active profile region so you never mix a us-east-1 Query with a us-west-2 table name.

Sources

UpdateGlobalTable — Amazon DynamoDB API Reference (verified 2026-07-13)
Global tables — Amazon DynamoDB Developer Guide (verified 2026-07-13)

ResourceNotFoundException — the table itself isn't found in the region/account.
ResourceInUseException — a replica change conflicts with the table's current state.
Learn: Global tables

References

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