DynamoDB ResourceNotFoundException: Causes and How to Fix It

ResourceNotFoundException is one of the most common — and most confusing — errors in DynamoDB, because it usually fires when your table does exist. The full message is typically:

ResourceNotFoundException: Requested resource not found

or, on some operations:

ResourceNotFoundException: Cannot do operations on a non-existent table

The key thing to understand: this error is about the table or index not being found where you’re looking — it is never about a missing item. A GetItem for a key that doesn’t exist returns an empty response, not this exception. So when you see ResourceNotFoundException, the fix is almost always in your configuration, not your data.

Here are the causes, ordered by how often they’re the real culprit.

1. Wrong region (the #1 cause)

DynamoDB tables are region-scoped. A table named Orders in us-east-1 simply does not exist in us-west-2 — they’re different namespaces. If your code, CLI profile, or environment resolves to a different region than the one where you created the table, you get ResourceNotFoundException even though the table is right there in the console.

Check what region is actually in effect:

# What region will the CLI use for this call?
aws configure get region
aws configure get region --profile my-profile

# List the tables that actually exist in a given region
aws dynamodb list-tables --region us-east-1

In application code, the region can come from (in resolution order) an explicit client config, AWS_REGION / AWS_DEFAULT_REGION, the shared config file, or instance metadata. The one you think is set is often not the one that wins. Log it:

// AWS SDK v3
const client = new DynamoDBClient({});
console.log("region:", await client.config.region());

2. Wrong endpoint — local vs. cloud

If you develop against DynamoDB Local or LocalStack, your client points at something like http://localhost:8000. Tables created there live only there. Point the same client at real AWS (or vice versa) and every table is suddenly “not found.”

The reverse bites too: a leftover endpoint override in a config file silently sends production code to localhost, where nothing exists.

// This client only sees tables created in DynamoDB Local
const client = new DynamoDBClient({ endpoint: "http://localhost:8000", region: "us-east-1" });

See Working with DynamoDB Local for how local endpoints and regions interact.

3. Table name typo or wrong environment

Table names are case-sensitive and exact. Orders, orders, and orders-prod are three different tables. Common variants:

• A trailing space or hidden character from a copy-paste.
• An environment suffix mismatch — code asks for orders, the deployed table is orders-staging.
• An interpolated name where a variable was empty, producing orders- or undefined.

Log the exact string you’re sending:

console.log(JSON.stringify({ TableName: tableName }));

4. Querying an index that doesn’t exist

ResourceNotFoundException also fires when you Query a Global or Local Secondary Index by a name that isn’t defined on the table — or one that hasn’t finished building. A GSI created moments ago is CREATING before it’s ACTIVE, and querying it early fails.

# See which indexes exist and their status
aws dynamodb describe-table --table-name Orders \
  --query "Table.GlobalSecondaryIndexes[].{Name:IndexName,Status:IndexStatus}"

Make sure IndexName in your query matches an index that is ACTIVE.

5. Timing — the table isn’t ACTIVE yet

CreateTable is asynchronous. Right after it returns, the table is in CREATING state and reads/writes fail with ResourceNotFoundException until it’s ACTIVE. In scripts and tests, wait for it:

aws dynamodb wait table-exists --table-name Orders --region us-east-1

Most SDKs ship an equivalent waiter. The same applies to a table you just deleted: a DeleteTable leaves it DELETING for a while, and calls race against that window.

6. IAM: a permission that looks like “not found”

Usually a missing permission gives AccessDeniedException, but a policy that scopes access to specific table ARNs can produce confusing results if the ARN — including its region and account id — doesn’t match the table you’re addressing. If everything above checks out, verify the resource ARN in your IAM policy matches the table’s real region and account.

A fast diagnostic checklist

Work down this list and you’ll find it in a minute or two:

1. Region — does list-tables in the region your code uses actually show the table?
2. Endpoint — is there a localhost/LocalStack endpoint override leaking in (or missing)?
3. Exact name — log the raw TableName; check case, suffixes, empty interpolation.
4. Index — if querying an index, does it exist and is it ACTIVE?
5. State — is the table itself ACTIVE (not CREATING/DELETING)?
6. IAM ARN — does the policy’s resource ARN match the table’s region + account?

See it instead of guessing

Most ResourceNotFoundException bugs come from a mismatch between the region/account/endpoint you think you’re on and the one you actually are. A GUI that shows every account, region and table side by side makes that mismatch obvious at a glance — no CLI archaeology.

Tablyne is a native DynamoDB GUI that lists your tables across all profiles and regions in one place, so “wrong region” stops being a silent failure. Download it free and connect a profile to see exactly where your tables live.