AWS amazondynamodb documentation change
Summary
Updated documentation structure and content for DynamoDB global tables, including new sections about MREC/MRSC consistency modes, expanded technical details about replication mechanics, conflict resolution, region evacuation, and additional resource links.
Security assessment
The changes focus on operational guidance, consistency models, and architectural best practices rather than addressing security vulnerabilities or introducing security-specific features. While MRSC's synchronous replication improves data consistency (a reliability aspect), this is not framed as a security control. No mentions of encryption, IAM, access controls, or vulnerability mitigations.
Diff
diff --git a/amazondynamodb/latest/developerguide/bp-global-table-design.md b/amazondynamodb/latest/developerguide/bp-global-table-design.md index d3c35b2e7..a22ce902a 100644 --- a//amazondynamodb/latest/developerguide/bp-global-table-design.md +++ b//amazondynamodb/latest/developerguide/bp-global-table-design.md @@ -5 +5 @@ -Global table designKey factsUse cases +Key factsKey facts about MRECKey facts about MRSCUse casesConclusion and resources @@ -7 +7 @@ Global table designKey factsUse cases -# Best practices for DynamoDB global table design +# Using DynamoDB global tables @@ -9 +9 @@ Global table designKey factsUse cases -Global tables build on Amazon DynamoDB’s global footprint to provide you with a fully managed, multi-Region, and multi-active database that delivers fast, local, read and write performance for massively scaled, global applications. With global tables your data replicates automatically across your choice of AWS Regions. Because global tables use existing DynamoDB APIs, no changes to your application will be needed. There are no upfront costs or commitments for using global tables, and you pay only for the resources you use. +Global tables build on Amazon DynamoDB’s global footprint to provide you with a fully managed, multi-Region, and multi-active database that can deliver fast and local, read and write performance for massively scaled, global applications. Global tables replicate your DynamoDB tables automatically across your choice of AWS Regions. No application changes are required because global tables use existing DynamoDB APIs. There are no upfront costs or commitments for using global tables, and you pay only for the resources you use. @@ -11 +11,3 @@ Global tables build on Amazon DynamoDB’s global footprint to provide you with -###### Topics +This guide explains how to use DynamoDB global tables effectively. It provides key facts about global tables, explains the feature’s primary use cases, describes the two consistency modes, introduces a taxonomy of three different write models you should consider, walks through the four main request routing choices you might implement, discusses ways to evacuate a Region that’s live or a Region that’s offline, explains how to think about throughput capacity planning, and provides a checklist of things to consider when you deploy global tables. + +This guide fits into a larger context of AWS multi-Region deployments, as covered in the [AWS Multi-Region Fundamentals](https://docs.aws.amazon.com/prescriptive-guidance/latest/aws-multi-region-fundamentals/introduction.html) whitepaper and the [Data resiliency design patterns with AWS](https://www.youtube.com/watch?v=7IA48SOX20c) video. @@ -13 +15 @@ Global tables build on Amazon DynamoDB’s global footprint to provide you with - * Prescriptive guidance for DynamoDB global table design +###### Topics @@ -17 +19,5 @@ Global tables build on Amazon DynamoDB’s global footprint to provide you with - * DynamoDB global table use cases + * Key facts about MREC + + * Key facts about MRSC + + * MREC DynamoDB global table use cases @@ -21 +27 @@ Global tables build on Amazon DynamoDB’s global footprint to provide you with - * [Request routing with DynamoDB global tables](./bp-global-table-design.prescriptive-guidance.request-routing.html) + * [Routing strategies in DynamoDB](./bp-global-table-design.prescriptive-guidance.request-routing.html) @@ -23 +29 @@ Global tables build on Amazon DynamoDB’s global footprint to provide you with - * [Evacuating a Region with DynamoDB global tables](./bp-global-table-design.prescriptive-guidance.evacuation.html) + * [Evacuation processes](./bp-global-table-design.prescriptive-guidance.evacuation.html) @@ -27,2 +33 @@ Global tables build on Amazon DynamoDB’s global footprint to provide you with - * [Preparation checklist for DynamoDB global tables and Frequently Asked Questions](./bp-global-table-design.prescriptive-guidance.checklist-and-faq.html) - + * [Preparation checklist for DynamoDB global tables](./bp-global-table-design.prescriptive-guidance.checklist-and-faq.html) @@ -29,0 +35 @@ Global tables build on Amazon DynamoDB’s global footprint to provide you with + * Conclusion and resources @@ -32 +37,0 @@ Global tables build on Amazon DynamoDB’s global footprint to provide you with -## Prescriptive guidance for DynamoDB global table design @@ -34 +38,0 @@ Global tables build on Amazon DynamoDB’s global footprint to provide you with -Efficient use of global tables requires careful considerations of factors like your preferred write mode, routing model, and evacuation processes. You must instrument your application across every Region and be ready to adjust your routing or perform an evacuation to maintain global health. The reward is having a globally distributed data set with low-latency reads and writes and a 99.999% service level agreement. @@ -38 +42,5 @@ Efficient use of global tables requires careful considerations of factors like y - * There are two versions of global tables: the current version [Global Tables version 2019.11.21 (Current)](./GlobalTables.html) (sometimes called "V2"), and [Global tables version 2017.11.29 (Legacy)](./globaltables.V1.html) (sometimes called "V1"). This guide focuses exclusively on the current version, V2. + * There are two versions of global tables: the current version [Global Tables version 2019.11.21 (Current)](./GlobalTables.html) (sometimes called "V2"), and [Global tables version 2017.11.29 (Legacy)](./globaltables.V1.html) (sometimes called "V1"). This guide focuses exclusively on the current version. + + * DynamoDB (without global tables) is a Regional service, which means that it is highly available and intrinsically resilient to failures of infrastructure, including the failure of an entire Availability Zone. A single-Region DynamoDB table is designed for 99.99% availability. For more information, see the [DynamoDB service-level agreement](https://aws.amazon.com/dynamodb/sla/) (SLA). + + * A DynamoDB global table replicates its data between two or more Regions. A multi-Region DynamoDB table is designed for 99.999% availability. With proper planning, global tables can help create an architecture that is resilient to Regional failures. @@ -40 +48 @@ Efficient use of global tables requires careful considerations of factors like y - * Without the use of global tables, DynamoDB is a Regional service. It is highly available and intrinsically resilient to failures of infrastructure with a Region, including the failure of an entire availability zone (AZ). A single-Region DynamoDB table has a 99.99% availability [https://aws.amazon.com/dynamodb/sla/](https://aws.amazon.com/dynamodb/sla/)Service Level Agreement (SLA). + * DynamoDB doesn’t have a global endpoint. All requests are made to a Regional endpoint that accesses the global table instance that’s local to that Region. @@ -42 +50 @@ Efficient use of global tables requires careful considerations of factors like y - * With the use of global tables, DynamoDB allows a table to replicate its data between two or more Regions. A multi-Region DynamoDB table has a 99.999% availability SLA. With proper planning, global tables can help create an architecture that is resilient and resists Regional failures. + * Calls to DynamoDB should not go across Regions. The best practice is for an application that is homed to one Region to directly access only the local DynamoDB endpoint for its Region. If problems are detected within a Region (in the DynamoDB layer or in the surrounding stack), end user traffic should be routed to a different application endpoint that’s hosted in a different Region. Global tables ensure that the application homed in every Region has access to the same data. @@ -44 +51,0 @@ Efficient use of global tables requires careful considerations of factors like y - * Global tables employ an active-active replication model. From the perspective of DynamoDB, the table in each Region has equal standing to accept read and write requests. After receiving a write request, the local replica table will replicate the write to other participating Regions in the background. @@ -46 +52,0 @@ Efficient use of global tables requires careful considerations of factors like y - * Items are replicated individually. Items updated within a single transaction may not be replicated together. @@ -48 +54,14 @@ Efficient use of global tables requires careful considerations of factors like y - * Each table partition in the source Region replicates its writes in parallel with every other partition. The sequence of writes within the remote Region may not match the sequence of writes that happened within the source Region. For more information about table partitions, see the blog post [Scaling DynamoDB: How partitions, hot keys, and split for heat impact performance](https://aws.amazon.com/blogs/database/part-3-scaling-dynamodb-how-partitions-hot-keys-and-split-for-heat-impact-performance/). + +### Consistency modes + +When you create a global table, you configure its consistency mode. Global tables support two consistency modes: multi-Region eventual consistency (MREC) and multi-Region strong consistency (MRSC) which was introduced in June 2025. + +If you don't specify a consistency mode when you create a global table, the global table defaults to MREC. A global table can't contain replicas that are configured with different consistency modes. You can't change a global table's consistency mode after its creation. + +## Key facts about MREC + + * Global tables that use MRSC also employ an active-active replication model. From the perspective of DynamoDB, the table in each Region has equal standing to accept read and write requests. After receiving a write request, the local replica table replicates the write operation to other participating remote Regions in the background. + + * Items are replicated individually. Items that are updated within a single transaction might not be replicated together. + + * Each table partition in the source Region replicates its write operations in parallel with every other partition. The sequence of write operations within a remote Region might not match the sequence of write operations that happened within the source Region. For more information about table partitions, see the blog post [Scaling DynamoDB: How partitions, hot keys, and split for heat impact performance](https://aws.amazon.com/blogs/database/part-3-scaling-dynamodb-how-partitions-hot-keys-and-split-for-heat-impact-performance/). @@ -52 +71,85 @@ Efficient use of global tables requires careful considerations of factors like y - * Amazon CloudWatch provides a `ReplicationLatency` metric for each Region pair. It is calculated based on looking at arriving items and comparing their arrival time with their initial write time and computing an average. Timings are stored within CloudWatch in the source Region. Viewing the average and maximum timings can help determine the average and worst-case replication lag. There is no SLA on this latency. + * Amazon CloudWatch provides a `ReplicationLatency` metric for each Region pair. It is calculated by looking at arriving items, comparing their arrival time with their initial write time, and computing an average. Timings are stored within CloudWatch in the source Region. Viewing the average and maximum timings can be useful for determining the average and worst-case replication lag. There is no SLA on this latency. + + * If an individual item is updated at about the same time (within this `ReplicationLatency` window) in two different Regions, and the second write operation happens before the first write operation was replicated, there’s a potential for write conflicts. Global tables that use MREC resolve such conflicts by using a last writer wins mechanism, based on the timestamp of the write operations. The first operation “loses” to the second operation. These conflicts aren’t recorded in CloudWatch or AWS CloudTrail. + + * Each item has a last write timestamp held as a private system property. The last writer wins approach is implemented by using a conditional write operation that requires the incoming item’s timestamp to be greater than the existing item’s timestamp. + + * A global table replicates all items to all participating Regions. If you want to have different replication scopes, you can create multiple global tables and assign each table different participating Regions. + + * The local Region accepts write operations even if the replica Region is offline or `ReplicationLatency` grows. The local table continues to attempt replicating items to the remote table until each item succeeds. + + * In the unlikely event that a Region goes fully offline, when it comes back online later, all pending outbound and inbound replications will be retried. No special action is required to bring the tables back in sync. The _last writer wins_ mechanism ensures that the data eventually becomes consistent. + + * You can add a new Region to a DynamoDB MREC table at any time. DynamoDB handles the initial sync and ongoing replication. You can also remove a Region (even the original Region), and this will delete the local table in that Region. + + + + +## Key facts about MRSC + + * Global tables that use MRSC also employ an active-active replication model. From the perspective of DynamoDB, the table in each Region has equal standing to accept read and write requests. Item changes in an MRSC global table replica are **synchronously** replicated to at least one other Region before the write operation returns a successful response. + + * Strongly consistent read operations on any MRSC replica always return the latest version of an item. Conditional write operations always evaluate the condition expression against the latest version of an item. Updates always operate against the latest version of an item. + + * Eventually consistent read operations on an MRSC replica might not include changes that recently occurred in another Region, and might not even include changes that very recently occurred in the same Region. + + * A write operation fails with a `ReplicatedWriteConflictException` exception when it attempts to modify an item that is already being modified in another Region. Write operations that fail with the `ReplicatedWriteConflictException` exception can be retried and will succeed if the item is no longer being modified in another Region. + + * With MRSC, latencies are higher for write operations and for strongly consistent read operations. These operations require cross-Region communication. This communication can add latency that increases based on the round-trip latency between the Region being accessed and the nearest Region participating in the global table. For more information, see the AWS re:Invent 2024 presentation, [Multi-Region strong consistency with DynamoDB global tables](https://www.youtube.com/watch?v=R-nTs8ZD8mA). Eventually consistent read operations experience no extra latency. There is an open source [tester tool](https://github.com/awslabs/amazon-dynamodb-tools/tree/main/tester) that lets you experimentally calculate these latencies with your Regions. + + * Items are replicated individually. Global tables using MRSC do not support the transaction APIs. + + * A MRSC global table must be deployed in exactly three Regions. You can configure a MRSC global table with three replicas, or with two replicas and one witness. A witness is a component of an MRSC global table that contains recent data written to global table replicas. A witness provides an optional alternative to a full replica while supporting MRSC's availability architecture. You can't perform read or write operations on a witness. A witness doesn't incur storage or write costs. A witness is located within a different Region from the two replicas. + + * To create an MRSC global table, you add one replica and a witness, or add two replicas to an existing DynamoDB table that contains no data. You cannot add additional replicas to an existing MRSC global table. You can't delete a single replica or a witness from an MRSC global table. You can delete two replicas, or delete one replica and a witness, from an MRSC global table. The second scenario converts the remaining replica to a single-Region DynamoDB table. + + * You can determine whether an MRSC global table has a witness configured, and which Region in which it's configured, from the output of the DescribeTable API. The witness is owned and managed by DynamoDB and doesn't appear in your AWS account in the Region where it's configured. + + * MRSC global tables are available in the following 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), and Asia Pacific (Osaka) + + * MRSC global tables can't span Region sets. For example, an MRSC global table can't contain replicas from both US and EU Region sets. + + * Time to Live (TTL) isn't supported for MRSC global tables. + + * Local secondary indexes (LSIs) aren't supported for MRSC global tables. + + * CloudWatch Contributor Insights information is only reported for the Region in which an operation occurred. + + * The local Region accepts all read and write operations as long as there is a second Region that hosts a replica or witness to establish quorum. If a second Region isn't available, the local Region can only service eventually consistent reads. + + * In the unlikely event that a Region goes fully offline, when it comes back online later, it will automatically catch up. Until it's caught up, write operations and strongly consistent read operations will return errors. However, eventually consistent read operations will return the data that has so far been propagated into the Region, with usual local consistency behavior between the leader node and local replicas. No special action is required to bring the tables back in sync. + + + + +## MREC DynamoDB global table use cases + +MREC global tables provides these benefits: + + * **Lower-latency read operations.** Place a copy of the data closer to the end user to reduce network latency during read operations. The data is kept as fresh as the `ReplicationLatency` value. + + * **Lower-latency write operations.** You can write to a nearby region to reduce network latency and the time taken to achieve the write. The write traffic must be carefully routed to ensure no conflicts. Techniques for routing are discussed in more detail in [Routing strategies in DynamoDB](./bp-global-table-design.prescriptive-guidance.request-routing.html). + + * **Seamless Region migration.** You can add a new Region and delete the old Region to migrate a deployment from one Region to another without downtime at the data layer. + + + + +MREC and MRSC global tables both provide this benefit: + + * **Increased resiliency and disaster recovery.** If a Region has degraded performance or a full outage, you can evacuate it. To evacuate means moving away some or all requests going to that Region. Using global tables increases the [DynamoDB SLA](https://aws.amazon.com/dynamodb/sla/) for monthly uptime percentage from 99.99% to 99.999%. Using MREC supports a recovery point objective (RPO) and recovery time objective (RTO) measured in seconds. Using MRSC supports an RPO of zero. + +For example, Fidelity Investments presented at re:Invent 2022 on how they use DynamoDB global tables for their order management system. Their goal was to achieve reliably low latency processing at a scale they couldn't achieve with on-premises processing while also maintaining resilience to Availability Zone and Regional failures. + + + + +If your goal is resiliency and disaster recovery, MRSC tables have higher write latencies and higher strongly consistent read latencies, but support an RPO of zero. MREC global tables support an RPO equal to the replication delay between replicas, usually a few seconds depending on the replica Regions. + +## Conclusion and resources @@ -54 +157 @@ Efficient use of global tables requires careful considerations of factors like y - * If the same item is updated at about the same time (within this `ReplicationLatency` window) in two different Regions, and the second write happens before the first write was replicated, there's a potential for write conflicts. Global tables resolves such conflicts with a _last writer wins_ mechanism, based on the timestamp of the writes. The first write "loses" to the second write. These conflicts are not recorded in CloudWatch or AWS CloudTrail. +DynamoDB global tables have very few controls but still require careful consideration. You must determine your write mode, routing model, and evacuation processes. You must instrument your application across every Region and be ready to adjust your routing or perform an evacuation to maintain global health. The reward is having a globally distributed dataset with low-latency read and write operations that is designed for 99.999% availability. @@ -56 +159 @@ Efficient use of global tables requires careful considerations of factors like y - * Each item has a last write timestamp held as a private system property. The _last writer wins_ approach is implemented by using a conditional write that requires the incoming item’s timestamp be greater than the existing item’s timestamp. +For more information about DynamoDB global tables, see the following resources: @@ -58 +161 @@ Efficient use of global tables requires careful considerations of factors like y - * A global table will replicate all items to all participating Regions. If you want to have different replication scopes, you can create different tables and give each of the tables different participating Regions. + * [DynamoDB documentation](https://docs.aws.amazon.com/dynamodb/) @@ -60 +163 @@ Efficient use of global tables requires careful considerations of factors like y - * Writes will be accepted to the local Region even if the replica Region is offline or the `ReplicationLatency` grows. The local table continues to attempt replicating items to the remote table until each item succeeds. + * [Amazon Application Recovery Controller](https://aws.amazon.com/application-recovery-controller/) @@ -62 +165 @@ Efficient use of global tables requires careful considerations of factors like y - * In the unlikely event a Region goes fully offline, when it later comes back online all pending outbound and inbound replications will be retried. No special action is required to bring the tables back in sync. The _last writer wins_ mechanism ensures the data will eventually become consistent. + * [Readiness check in ARC](https://docs.aws.amazon.com/r53recovery/latest/dg/recovery-readiness.html) (AWS documentation) @@ -64 +167 @@ Efficient use of global tables requires careful considerations of factors like y - * You can add a new Region to a DynamoDB table at any time. DynamoDB will handle the initial sync and ongoing replication. If a Region is removed, even if it's the original Region, that will only delete the table for that Region. + * [Route 53 routing policies](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html) @@ -66 +169 @@ Efficient use of global tables requires careful considerations of factors like y - * DynamoDB does not have a global endpoint. All requests are made to a regional endpoint, which then accesses the global table instance that’s local to that Region. + * [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/) @@ -68 +171 @@ Efficient use of global tables requires careful considerations of factors like y - * Calls to DynamoDB should not go cross-Region. The best practice is for the compute layer in one Region to directly access only the local DynamoDB endpoint for that Region. If problems are detected within a Region, whether those problems are in the DynamoDB layer or in the surrounding stack, then the end user traffic should be routed to a different compute layer hosted in a different Region. Thanks to global table replication, the different Region will already have a local copy of the same data for it to locally work with. In some circumstances the compute layer in one Region may pass the request onward to another Region’s compute layer for processing, but this should not directly access the remote DynamoDB endpoint. For more information on this particular use case see [Compute-layer request routing](./bp-global-table-design.prescriptive-guidance.request-routing.html#bp-global-table-design.prescriptive-guidance.request-routing.compute). + * [DynamoDB service-level agreement](https://aws.amazon.com/dynamodb/sla/) @@ -69,0 +173 @@ Efficient use of global tables requires careful considerations of factors like y + * [AWS Multi-Region Fundamentals](https://docs.aws.amazon.com/prescriptive-guidance/latest/aws-multi-region-fundamentals/introduction.html) (AWS whitepaper) @@ -70,0 +175 @@ Efficient use of global tables requires careful considerations of factors like y + * [Data resiliency design patterns with AWS](https://www.youtube.com/watch?v=7IA48SOX20c) (AWS re:Invent 2022 presentation) @@ -71,0 +177 @@ Efficient use of global tables requires careful considerations of factors like y + * [How Fidelity Investments and Reltio modernized with Amazon DynamoDB](https://www.youtube.com/watch?v=QUpV5MDu4Ys&t=706s) (AWS re:Invent 2022 presentation) @@ -73 +179 @@ Efficient use of global tables requires careful considerations of factors like y -## DynamoDB global table use cases + * [Multi-Region design patterns and best practices](https://www.youtube.com/watch?v=ilgpzlE7Hds&t=1882s) (AWS re:Invent 2022 presentation) @@ -75 +181 @@ Efficient use of global tables requires careful considerations of factors like y -Global tables provides these common benefits: + * [Disaster Recovery (DR) Architecture on AWS, Part III: Pilot Light and Warm Standby](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/) (AWS blog post)