Question: Is a DynamoDB table Region-specific?

Answer

Yes. A DynamoDB table is a regional resource: it exists in the one AWS Region where you created it, its ARN includes that Region (arn:aws:dynamodb:eu-west-1:123456789012:table/Orders), and you reach it through that Region's endpoint. Within the Region, DynamoDB replicates the table across multiple Availability Zones for you.

Two consequences trip people up:

• A client configured for the wrong Region gets ResourceNotFoundException, even though the table exists. Check the Region of your SDK client, AWS_REGION or CLI profile first.
• Table names are unique per account and Region, so Orders can exist separately in us-east-1 and eu-west-1, with different data.

Using a table in several Regions

Turn it into a global table. DynamoDB keeps a full replica in each Region you add and replicates writes between them, and your application uses its local replica. Global tables have two modes:

• Multi-Region eventual consistency (MREC), the default: changes typically reach the other replicas within a second, and conflicting writes resolve as last writer wins.
• Multi-Region strong consistency (MRSC), generally available since June 2025: exactly three Regions, using three replicas or two replicas and a witness. Strong reads return the latest item at any replica; a witness cannot serve reads or writes. MRSC does not support transactions, TTL or local secondary indexes.

Moving a table to another Region

There's no move operation. You can:

1. For an MREC table, add a replica in the target Region, wait until it is active, and switch the application to it. Verify reads and writes before removing the old replica. MRSC has different replica-management restrictions.
2. Export the table to S3 and import the files into a new table in the target Region. The bucket can be in a different Region from the table.

Copy a DynamoDB table to another Region walks through these options.

Source: AWS DynamoDB documentation.