GlobalTableNotFoundException

TL;DR — DescribeGlobalTable / UpdateGlobalTable only see version 2017.11.29 (Legacy) global tables. A global table built on version 2019.11.21 (Current) — which is what you should be using — is managed as a regular table with replicas through DescribeTable / UpdateTable, and the legacy APIs report it as not existing. Check which version you're on before assuming the table is gone.

What it means

GlobalTableNotFoundException: The specified global table does not exist.

# what the engine actually returns, reproduced against the live DynamoDB service:
GlobalTableNotFoundException: Global table not found: Global table with name: 'no-such-global-table' does not exist.

DynamoDB has two global-table generations with two disjoint API surfaces. The legacy (2017.11.29) generation registers a named "global table" object that DescribeGlobalTable, UpdateGlobalTable, and UpdateGlobalTableSettings operate on. The current (2019.11.21) generation has no such object — replicas live on the table itself — so those legacy calls answer with this exception even though your table replicates perfectly well.

Why it happens

The table is a current-version (2019.11.21) global table — by far the usual cause: the legacy API simply doesn't index it.
No global table was ever created under that name — the table exists but has no replicas, or replication setup failed earlier.
Wrong Region or a name typo — the legacy global-table registration is looked up by exact name.

How to fix it

Determine the version:

aws dynamodb describe-table --table-name orders \
  --query 'Table.GlobalTableVersion'
# "2019.11.21" → use DescribeTable/UpdateTable, not the legacy APIs

Manage current-version replicas through UpdateTable:
```
aws dynamodb update-table --table-name orders \
  --replica-updates '[{"Create": {"RegionName": "eu-west-1"}}]'
```
and inspect them with describe-table (the Replicas field) instead of describe-global-table.
On legacy tooling? If you genuinely operate 2017.11.29 global tables, verify the name and Region of the registration — and plan the upgrade to 2019.11.21, which AWS recommends for flexibility and lower replicated-write cost.
Creating from scratch: create the table, then add replicas via UpdateTable — don't reach for CreateGlobalTable (legacy) in new code.
Confirm the Region on every call. Legacy global-table APIs are Region-scoped; a name that exists in us-east-1 may not resolve from eu-west-1.

Check size in DynoTable

DynoTable connects to every Region from one window — switch with ⌘P and open the same table name in each profile to see whether replicas exist and serve data. The table sidebar shows replication metadata without calling legacy global-table APIs.

Before adding a replica, estimate replicated write cost with the pricing calculator. Configure each Region under Settings → Profiles and run Test Connection before you run UpdateTable replica updates. See Connect to AWS and Install. If legacy tooling calls DescribeGlobalTable, check GlobalTableVersion on DescribeTable first — Current-version tables return 2019.11.21 and must be managed through UpdateTable. Legacy APIs cannot see them even when replication is healthy. Upgrade tooling to call UpdateTable with ReplicaUpdates for Current-version tables instead of CreateGlobalTable.

Sources

DynamoDB global tables versions (verified 2026-07-13)
UpdateTable — Amazon DynamoDB API Reference (verified 2026-07-13)

Global table version mismatch — the same two-generations split, hit from the upgrade path.
ReplicaNotFoundException — the Region isn't part of the replication group.
ReplicaAlreadyExistsException — the Region already is.
Learn: DynamoDB global tables

References

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