Amazon DynamoDB is available in multiple AWS Regions around the world. Each Region is independent and isolated from other AWS Regions. For example, if you have a table called People in the us-east-2 Region and another table named People in the us-west-2 Region, these are considered two entirely separate tables.
The below are the list of AWS regions with their respective code where DynamoDB is available:
- US East (Ohio) : us-east-2
- US East (N. Virginia) : us-east-1
- US West (N. California) : us-west-1
- US West (Oregon) : us-west-2
- Africa (Cape Town) : af-south-1
- Asia Pacific (Hong Kong) : ap-east-1
- Asia Pacific (Mumbai) : ap-south-1
- Asia Pacific (Osaka-Local) : ap-northeast-3
- Asia Pacific (Seoul) : ap-northeast-2
- Asia Pacific (Singapore) : ap-southeast-1
- Asia Pacific (Sydney) : ap-southeast-2
- Asia Pacific (Tokyo) : ap-northeast-1
- Canada (Central) : ca-central-1
- China (Beijing) : cn-north-1
- China (Ningxia) : cn-northwest-1
- Europe (Frankfurt) : eu-central-1
- Europe (Ireland) : eu-west-1
- Europe (London) : eu-west-2
- Europe (Milan) : eu-south-1
- Europe (Paris) : eu-west-3
- Europe (Stockholm) : eu-north-1
- Middle East (Bahrain) : me-south-1
- South America (São Paulo) : sa-east-1
Every AWS Region consists of multiple distinct locations called Availability Zones. Each Availability Zone is isolated from failures in other Availability Zones and provides inexpensive, low-latency network connectivity to other Availability Zones in the same region. This allows rapid replication of your data among multiple Availability Zones in a Region.
When your application writes data to a DynamoDB table and receives an HTTP 200 response (OK), the write has occurred and is durable. The data is eventually consistent across all storage locations, usually within one second or less.
DynamoDB supports eventually consistent and strongly consistent reads.
Eventually Consistent Reads:
When you read data from a DynamoDB table, the response might not reflect the results of a recently completed write operation. The response might include some stale data. If you repeat your read request after a short time, the response should return the latest data.
Strongly Consistent Reads:
When you request a strongly consistent read, DynamoDB returns a response with the most up-to-date data, reflecting the updates from all prior write operations that were successful. However, this consistency comes with some disadvantages:
- A strongly consistent read might not be available if there is a network delay or outage. In this case, DynamoDB may return a server error (HTTP 500).
- Strongly consistent reads may have higher latency than eventually consistent reads.
- Strongly consistent reads are not supported on global secondary indexes.
- Strongly consistent reads use more throughput capacity than eventually consistent reads.
Note: DynamoDB uses eventually consistent read unless stated otherwise.