Amazon DynamoDB Global Tables

Amazon DynamoDB Global Tables

  • DynamoDB Global Tables is a fully managed, serverless, multi-Region, multi-active database.
  • Global tables provide 99.999% availability, increased application resiliency, and improved business continuity.
  • Global table’s automatic cross-Region replication capability helps achieve fast, local read and write performance and regional fault tolerance for database workloads.
  • Applications can now perform reads and writes to DynamoDB in AWS Regions around the world, with changes in any Region propagated to every Region where a table is replicated.
  • Global Tables help in building applications to advantage of data locality to reduce overall latency.
  • Global Tables replicates data among Regions within a single AWS account.

Global Tables Working

  • Global Table is a collection of one or more replica tables, all owned by a single AWS account.
  • A single Amazon DynamoDB global table can only have one replica table per AWS Region.
  • Each replica table stores the same set of data items, has the same table name, and the same primary key schema.
  • When an application writes data to a replica table in one Region, DynamoDB replicates the writes to other replica tables in the other AWS Regions.
  • All replicas in a global table share the same table name, primary key schema, and item data.

Consistency Modes

  • When creating a global table, a consistency mode must be configured.
  • Global tables support two consistency modes: Multi-Region Eventual Consistency (MREC) and Multi-Region Strong Consistency (MRSC).
  • If no consistency mode is specified, the global table defaults to MREC.
  • A global table cannot contain replicas configured with different consistency modes.
  • Consistency mode cannot be changed after creation.

Multi-Region Eventual Consistency (MREC) – Default

  • MREC is the default consistency mode for global tables.
  • Item changes are asynchronously replicated to all other replicas, typically within a second or less.
  • Conflict Resolution: Uses Last Write Wins approach based on the latest internal timestamp on a per-item basis.
  • Consistency Behavior:
    • Supports eventual consistency for cross-Region reads.
    • Supports strong consistency for same-Region reads (returns latest version if item was last updated in that Region).
    • May return stale data for strongly consistent reads if the item was last updated in a different Region.
  • Recovery Point Objective (RPO): Equal to replication delay between replicas (usually a few seconds).
  • Replica Management:
    • Create by adding a replica to an existing DynamoDB table.
    • Can add replicas to expand to more Regions or remove replicas if no longer needed.
    • Can have a replica in any Region where DynamoDB is available.
    • No performance impact when adding replicas.
  • Requirements: Requires DynamoDB Streams enabled with New and Old image settings.
  • Use Cases:
    • Applications that can tolerate stale data from strongly consistent reads if data was updated in another Region.
    • Prioritize lower write and strongly consistent read latencies over multi-Region read consistency.
    • Multi-Region high availability strategy can tolerate RPO greater than zero.

Multi-Region Strong Consistency (MRSC) – January 2025

  • Announced at AWS re:Invent 2024 (preview) and generally available in January 2025.
  • Item changes are synchronously replicated to at least one other Region before the write operation returns a successful response.
  • Zero RPO: Provides Recovery Point Objective (RPO) of zero for highest resilience.
  • Consistency Behavior:
    • Strongly consistent read operations on any MRSC replica always return the latest version of an item.
    • Conditional writes always evaluate against the latest version of an item.
    • Provides strong read-after-write consistency across all Regions.
  • Deployment Requirements:
    • Must be deployed in exactly three Regions.
    • Can configure with three replicas OR two replicas + one witness.
    • Witness: A component that contains data written to replicas and supports MRSC’s availability architecture. Cannot perform read/write operations on a witness. Witness is owned and managed by DynamoDB.
  • Regional Availability: Available in three Region sets:
    • US Region set: US East (N. Virginia), US East (Ohio), US West (Oregon)
    • EU Region set: Europe (Ireland), Europe (London), Europe (Paris), Europe (Frankfurt)
    • AP Region set: Asia Pacific (Tokyo), Asia Pacific (Seoul), Asia Pacific (Osaka)
    • MRSC global tables cannot span Region sets (e.g., cannot mix US and EU Regions).
  • Creation Requirements:
    • Create by adding one replica and a witness OR two replicas to an existing DynamoDB table.
    • Table must be empty when converting to MRSC (existing items not supported).
    • Cannot add additional replicas after creation.
    • Cannot delete a single replica or witness (must delete two replicas or one replica + witness to convert back to single-Region table).
  • Write Conflicts: Write operation fails with ReplicatedWriteConflictException when attempting to modify an item already being modified in another Region. Failed writes can be retried.
  • Limitations:
    • Time to Live (TTL): Not supported
    • Local Secondary Indexes (LSIs): Not supported
    • Transactions: Not supported (TransactWriteItems and TransactGetItems return errors)
    • DynamoDB Streams: Not used for replication (can be enabled separately)
  • Performance Trade-off: Higher write and strongly consistent read latencies compared to MREC.
  • Use Cases:
    • Need strongly consistent reads across multiple Regions.
    • Prioritize global read consistency over lower write latency.
    • Multi-Region high availability strategy requires RPO of zero.
    • Financial applications, inventory management, or any system requiring strict consistency.

Pricing Reduction (November 2024)

  • Effective November 1, 2024, DynamoDB reduced prices for global tables by up to 67%.
  • On-demand mode: Global tables cost 67% less than before.
  • Provisioned capacity mode: Global tables cost 33% less than before.
  • Makes global tables significantly more cost-effective for multi-Region deployments.

Replication and Throughput

  • MREC Replication:
    • Uses DynamoDB Streams to replicate changes.
    • Streams are enabled by default on all replicas and cannot be disabled.
    • Replication process may combine multiple changes into a single replicated write.
    • Stream records are ordered per-item but ordering between items may differ between replicas.
  • MRSC Replication:
    • Does not use DynamoDB Streams for replication.
    • Streams can be enabled separately if needed.
    • Stream records are identical for every replica, including ordering.
  • Provisioned Mode:
    • Replication consumes write capacity.
    • Auto scaling settings for read and write capacities are synchronized between replicas.
    • Read capacity can be independently configured per replica using ProvisionedThroughputOverride.
  • On-demand Mode:
    • Write capacity is automatically synchronized across all replicas.
    • DynamoDB automatically adjusts capacity based on traffic.

Monitoring and Testing

  • Replication Latency (MREC only):
    • MREC global tables publish ReplicationLatency metric to CloudWatch.
    • Tracks elapsed time between item write in one replica and appearance in another replica.
    • Expressed in milliseconds for every source-destination Region pair.
    • MRSC global tables do not publish this metric (synchronous replication).
  • Fault Injection Testing:
    • Both MREC and MRSC integrate with AWS Fault Injection Service (AWS FIS).
    • Can simulate Region isolation by pausing replication to/from a selected replica.
    • Test error handling, recovery mechanisms, and multi-Region traffic shift behavior.

Additional Features and Considerations

  • Time to Live (TTL):
    • MREC: Supported. TTL settings synchronized across all replicas. TTL deletes replicated to all replicas (charged for replicated deletes).
    • MRSC: Not supported.
  • Transactions:
    • MREC: Supported but only atomic within the Region where invoked. Not replicated as a unit.
    • MRSC: Not supported.
  • Point-in-Time Recovery (PITR):
    • Can be enabled on each local replica independently.
    • PITR settings are not synchronized between replicas.
  • DynamoDB Accelerator (DAX):
    • Writes to global table replicas bypass DAX, updating DynamoDB directly.
    • DAX caches can become stale and are only refreshed when cache TTL expires.
  • Settings Synchronization:
    • Always synchronized: Capacity mode, write capacity, GSI definitions, encryption, TTL (MREC)
    • Can be overridden per replica: Read capacity, table class
    • Never synchronized: Deletion protection, PITR, tags, Contributor Insights

DynamoDB Global Tables vs. Aurora Global Databases

AWS Aurora Global Database vs DynamoDB Global Tables

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. A company is building a web application on AWS. The application requires the database to support read and write operations in multiple AWS Regions simultaneously. The database also needs to propagate data changes between Regions as the changes occur. The application must be highly available and must provide a latency of single-digit milliseconds. Which solution meets these requirements?
    1. Amazon DynamoDB global tables
    2. Amazon DynamoDB streams with AWS Lambda to replicate the data
    3. An Amazon ElastiCache for Redis cluster with cluster mode enabled and multiple shards
    4. An Amazon Aurora global database
  2. A financial services company requires a multi-Region database with zero data loss (RPO = 0) and strongly consistent reads across all Regions. Which DynamoDB global tables consistency mode should they use?
    1. Multi-Region Eventual Consistency (MREC)
    2. Multi-Region Strong Consistency (MRSC)
    3. Single-Region Strong Consistency
    4. Cross-Region Read Replicas
  3. A company wants to create a DynamoDB global table with MRSC for their inventory management system. They have existing data in a table in us-east-1. What must they do before converting to MRSC?
    1. Enable DynamoDB Streams on the table.
    2. Configure three replicas in different Regions.
    3. Empty the table of all existing data.
    4. Enable Point-in-Time Recovery (PITR).
  4. A company has a DynamoDB global table with MREC configured across us-east-1, eu-west-1, and ap-southeast-1. An item is updated simultaneously in us-east-1 and eu-west-1. How does DynamoDB resolve this conflict?
    1. The write in the primary Region takes precedence.
    2. Last Write Wins based on the latest internal timestamp.
    3. Both writes are rejected and must be retried.
    4. The write with the larger data size takes precedence.
  5. A company wants to deploy a DynamoDB global table with MRSC. They need replicas in us-east-1, eu-west-1, and ap-southeast-1. What will happen?
    1. The global table will be created successfully.
    2. The creation will fail because MRSC cannot span Region sets.
    3. The global table will be created with MREC instead.
    4. A witness will be automatically placed in a fourth Region.
  6. Which of the following features are NOT supported with DynamoDB MRSC global tables? (Select THREE)
    1. Time to Live (TTL)
    2. DynamoDB Streams
    3. Local Secondary Indexes (LSIs)
    4. Global Secondary Indexes (GSIs)
    5. Transaction operations (TransactWriteItems)
    6. Point-in-Time Recovery (PITR)
  7. A company has a DynamoDB global table with MREC. They perform a strongly consistent read in us-west-2, but the item was last updated in eu-west-1. What will the read return?
    1. The latest version of the item from eu-west-1.
    2. Potentially stale data (the version before the eu-west-1 update).
    3. An error indicating the item is being replicated.
    4. The read will be automatically redirected to eu-west-1.
  8. What is the typical replication latency for DynamoDB global tables with MREC?
    1. 5-10 seconds
    2. Within a second or less
    3. Within 5 minutes
    4. Synchronous (no latency)

References