AWS amazondynamodb documentation change
Summary
Updated documentation about DynamoDB global table request routing strategies with improved explanations, real-world examples (Vanguard Group), diagram references, and clarifications about regional failover mechanisms
Security assessment
Changes focus on architectural best practices, reliability improvements, and clarification of routing strategies. No specific security vulnerabilities or security feature enhancements are mentioned. Updates emphasize fault tolerance and performance rather than security controls.
Diff
diff --git a/amazondynamodb/latest/developerguide/bp-global-table-design.prescriptive-guidance.request-routing.md b/amazondynamodb/latest/developerguide/bp-global-table-design.prescriptive-guidance.request-routing.md index 521200462..6699d28cf 100644 --- a//amazondynamodb/latest/developerguide/bp-global-table-design.prescriptive-guidance.request-routing.md +++ b//amazondynamodb/latest/developerguide/bp-global-table-design.prescriptive-guidance.request-routing.md @@ -5 +5 @@ -Client-drivenCompute-layer routingRoute 53 routingGlobal Accelerator routing +Client-drivenCompute-layer routingRoute 53 routingGlobal Accelerator request routing @@ -7 +7 @@ Client-drivenCompute-layer routingRoute 53 routingGlobal Accelerator routing -# Request routing with DynamoDB global tables +# Routing strategies in DynamoDB @@ -11 +11 @@ Perhaps the most complex piece of a global table deployment is managing request -The global table provides each stack in the various Regions with a local copy of the same data. You might consider designing for a single stack in a single Region and anticipate making remote calls to a secondary Region’s DynamoDB endpoint if there’s an issue with the local DynamoDB table. This is not best practice. The latencies associated with going across Regions might be 100 times higher than for local access. A back-and-forth series of 5 requests might take milliseconds when performed locally but seconds when crossing the globe. It’s better to route the end user to another Region for processing. To ensure resiliency you need replication across multiple Regions, with replication of the compute layer as well as the data layer. +The global table provides each stack in the various Regions with a local copy of the same data. You might consider designing for a single stack in a single Region and anticipate making remote calls to a secondary Region’s DynamoDB endpoint if there’s an issue with the local DynamoDB table. This is not best practice. If there’s an issue in one Region that’s caused by DynamoDB (or, more likely, caused by something else in the stack or by another service that depends on DynamoDB), it’s best to route the end user to another Region for processing and use that other Region’s compute layer, which will talk to its local DynamoDB endpoint. This approach routes around the problematic Region entirely. To ensure resiliency, you need replication across multiple Regions: replication of the compute layer as well as the data layer. @@ -17 +17 @@ There are numerous alternative techniques to route an end user request to a Regi -With client-driven request routing, an end user client such as an application, a web page with JavaScript another client will keeps track of the valid application endpoints. In this case that will be application endpoints like an Amazon API Gateway rather than literal DynamoDB endpoints. The end user client uses its own embedded logic to choose which Region to communicate with. It may choose based on random selection, lowest observed latencies, highest observed bandwidth measurements, or locally-performed health checks. +With client-driven request routing, illustrated in the following diagram, the end user client (an application, a web page with JavaScript, or another client) keeps track of the valid application endpoints (for example, an Amazon API Gateway endpoint rather than a literal DynamoDB endpoint) and uses its own embedded logic to choose the Region to communicate with. It might choose based on random selection, lowest observed latencies, highest observed bandwidth measurements, or locally performed health checks. @@ -19 +19 @@ With client-driven request routing, an end user client such as an application, a - + @@ -21 +21 @@ With client-driven request routing, an end user client such as an application, a -The advantage to client-driven request routing is it can be adaptive to things such as real-world public internet traffic conditions to switch Regions should it notice any degraded performance. The client must be aware of all potential endpoints, but launching a new Regional endpoint is not a frequent occurrence. +As an advantage, client-driven request routing can adapt to things such as real-world public internet traffic conditions to switch Regions if it notices any degraded performance. The client must be aware of all potential endpoints, but launching a new Regional endpoint is not a frequent occurrence. @@ -23 +23 @@ The advantage to client-driven request routing is it can be adaptive to things s -With the _write to any Region_ mode, a client can unilaterally select its preferred endpoint. If its access to one Region becomes impaired, the client can route to another endpoint. +With _write to any Region_ mode, a client can unilaterally select its preferred endpoint. If its access to one Region becomes impaired, the client can route to another endpoint. @@ -25 +25 @@ With the _write to any Region_ mode, a client can unilaterally select its prefer -With the _write to one Region_ mode, the client will need a mechanism to route its writes to the currently active region. This could be as basic as empirically testing which region is presently accepting writes (noting any write rejections and falling back to an alternate) or as complex as calling a global coordinator to query for the current application state (perhaps built on the Route 53 Application Recovery Controller (ARC) routing control which provides a 5-region quorum-driven system to maintain global state for needs such as this). The client can decide if reads can go to any Region for eventual consistency or must be routed to the active region for strong consistency. For further information see [How Route 53 works](https://docs.aws.amazon.com/r53recovery/latest/dg/introduction-how-it-works.html). +With the _write to one Region_ mode, the client will need a mechanism to route its writes to the currently active region. This could be as basic as empirically testing which region is presently accepting writes (noting any write rejections and falling back to an alternate) or as complex as calling a global coordinator to query for the current application state (perhaps built on the Amazon Application Recovery Controller (ARC) (ARC) routing control which provides a 5-region quorum-driven system to maintain global state for needs such as this). The client can decide if reads can go to any Region for eventual consistency or must be routed to the active region for strong consistency. For further information see [How Route 53 works](https://docs.aws.amazon.com/r53recovery/latest/dg/introduction-how-it-works.html). @@ -33 +33 @@ For example, a financial services company that helps users manage their business -With compute-layer request routing, the code running in the compute layer decides whether it wants to process the request locally, or pass it to a copy of itself that's running in another Region. When you use the _write to one Region_ mode, the compute layer may detect that it’s not the active region and allow local read operations while forwarding all write operations onto another Region. This compute layer code must be aware of data topology and routing rules, and enforce them reliably based on the latest settings that specify which Regions are active for which data. The outer software stack within the Region doesn’t have to be aware of how read and write requests are routed by the microservice. In a robust design, the receiving Region validates whether it is the current primary for the write operation. If it isn’t, it generates an error that indicates that the global state needs to be corrected. The receiving Region might also buffer the write operation for a while if the primary Region is in the process of changing. In all cases, the compute stack in a Region writes only to its local DynamoDB endpoint, but the compute stacks might communicate with one another. +With compute-layer request routing, illustrated in the following diagram, the code that runs in the compute layer determines whether to process the request locally or pass it to a copy of itself that’s running in another Region. When you use the _write to one Region_ mode, the compute layer might detect that it’s not the active Region and allow local read operations while forwarding all write operations to another Region. This compute layer code must be aware of data topology and routing rules, and enforce them reliably, based on the latest settings that specify which Regions are active for which data. The outer software stack within the Region doesn’t have to be aware of how read and write requests are routed by the micro service. In a robust design, the receiving Region validates whether it is the current primary for the write operation. If it isn’t, it generates an error that indicates that the global state needs to be corrected. The receiving Region might also buffer the write operation for a while if the primary Region is in the process of changing. In all cases, the compute stack in a Region writes only to its local DynamoDB endpoint, but the compute stacks might communicate with one another. @@ -35 +35 @@ With compute-layer request routing, the code running in the compute layer decide - + @@ -37 +37 @@ With compute-layer request routing, the code running in the compute layer decide -In this scenario, let’s say a financial services company uses a follow-the-sun Single Primary model. They use a system and a library for this routing process. Their overall system maintains the global state, similar to AWS's ARC routing control. They use a global table to track which Region is the primary Region, and when the next primary switch is scheduled. All read and write operations go through the library, which coordinates with their system. The library allows read operations to be performed locally, at low latency. For write operations, the application checks if the local Region is the current primary Region. If so, the write operation completes directly. If not, the library forwards the write task to the library that's in the current primary Region. That receiving library confirms that it also considers itself the primary Region and raises an error if it isn’t, which indicates a propagation delay with the global state. This approach provides a validation benefit by not writing directly to a remote DynamoDB endpoint. +The Vanguard Group uses a system called Global Orchestration and Status Tool (GOaST) and a library called Global Multi-Region library (GMRlib) for this routing process, as presented at [re:Invent 2022](https://www.youtube.com/watch?v=ilgpzlE7Hds&t=1882s). They use a follow-the-sun single primary model. GOaST maintains the global state, similar to the ARC routing control discussed in the previous section. It uses a global table to track which Region is the primary Region and when the next primary switch is scheduled. All read and write operations go through GMRlib, which coordinates with GOaST. GMRlib allows read operations to be performed locally, at low latency. For write operations, GMRlib checks if the local Region is the current primary Region. If so, the write operation completes directly. If not, GMRlib forwards the write task to the GMRlib in the primary Region. That receiving library confirms that it also considers itself the primary Region and raises an error if it isn’t, which indicates a propagation delay with the global state. This approach provides a validation benefit by not writing directly to a remote DynamoDB endpoint. @@ -41 +41 @@ In this scenario, let’s say a financial services company uses a follow-the-sun -Amazon Application Recovery Controller (ARC) is a Domain Name Service (DNS) technology. With Route 53, the client requests its endpoint by looking up a well-known DNS domain name, and Route 53 returns the IP address corresponding to the regional endpoint(s) it thinks most appropriate. Route 53 has a [list of routing policies it uses to determine the appropriate region](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html). Route 53 also can do [ failover routing to route traffic away from regions that fail health checks.](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy-failover.html) +Amazon Application Recovery Controller (ARC) is a Domain Name Service (DNS) technology. With Route 53, the client requests its endpoint by looking up a well-known DNS domain name, and Route 53 returns the IP address corresponding to the regional endpoint(s) it thinks most appropriate. This is illustrated in the following diagram. Route 53 has a long list of routing policies it uses to determine the appropriate Region. It also can do failover routing to route traffic away from Regions that fail health checks. @@ -43 +43 @@ Amazon Application Recovery Controller (ARC) is a Domain Name Service (DNS) tech - + @@ -45 +45 @@ Amazon Application Recovery Controller (ARC) is a Domain Name Service (DNS) tech - * With _write to any Region_ mode, or if combined with the compute-layer request routing on the backend, Route 53 can be given full access to return the Region based on any complex internal rules such as the Region in closest network proximity, or closest geographic proximity, or any other choice. +With _write to any Region_ mode, or if combined with the compute-layer request routing on the backend, Route 53 can be given full access to return the Region based on any complex internal rules such as the Region in closest network proximity, or closest geographic proximity, or any other choice. @@ -47 +47 @@ Amazon Application Recovery Controller (ARC) is a Domain Name Service (DNS) tech - * With _write to one Region_ mode, Route 53 can be configured to return the currently active region (using Route 53 ARC). +With _write to one Region_ mode, you can configure Route 53 to return the currently active Region (using Route 53 ARC). If the client wants to connect to a passive Region (for example, for read operations), it could look up a different DNS name. @@ -51,5 +51 @@ Amazon Application Recovery Controller (ARC) is a Domain Name Service (DNS) tech -Clients cache the IP addresses in the response from Route 53 for a time indicated by the time to live (TTL) setting on the domain name. A longer TTL extends the recovery time objective (RTO) for all clients to recognize the new endpoint. A value of 60 seconds is typical for failover use. Not all software perfectly adheres to DNS TTL expiration. - - * With _write to your Region_ mode, it’s best to avoid Route 53 unless you're also using compute-layer request routing. - - +Clients cache the IP addresses in the response from Route 53 for a time indicated by the time to live (TTL) setting on the domain name. A longer TTL extends the recovery time objective (RTO) for all clients to recognize the new endpoint. A value of 60 seconds is typical for failover use. Not all software perfectly adheres to DNS TTL expiration, and there might be multiple levels of DNS caching, such as at the operating system, virtual machine, and application. @@ -56,0 +53 @@ Clients cache the IP addresses in the response from Route 53 for a time indicate +With _write to your Region_ mode, it’s best to avoid Route 53 unless you're also using compute-layer request routing. @@ -60,7 +57 @@ Clients cache the IP addresses in the response from Route 53 for a time indicate -A client uses [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/) to looks up the well-known domain name in Route 53. However, instead of getting back an IP address that corresponds to a regional endpoint the client receives an anycast static IP address which routes to the nearest AWS edge location. Starting from that edge location, all traffic gets routed on the private AWS network and to some endpoint (such as a load balancer or API Gateway) in a Region chosen by routing rules that are maintained within Global Accelerator. Compared with routing based on Route 53 rules, Global Accelerator request routing has lower latencies because it reduces the amount of traffic on the public internet. In addition, because Global Accelerator doesn’t depend on DNS TTL expiration to change routing rules it can adjust routing more quickly. - - - - * With _write to any Region_ mode, or if combined with the compute-layer request routing on the back- end, Global Accelerator works seamlessly. The client connects to the nearest edge location and need not be concerned with which Region receives the request. - - * With _write to one Region_ Global Accelerator routing rules must send requests to the currently active Region. You can use health checks that artificially report a failure on any Region that’s not considered by your global system to be the active Region. As with DNS, it’s possible to use an alternative DNS domain name for routing read requests if the requests can be from any Region. +With [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/), illustrated in the following diagram, a client looks up the well-known domain name in Route 53. However, instead of getting back an IP address that corresponds to a Regional endpoint, the client receives an anycast static IP address which routes to the nearest AWS edge location. Starting from that edge location, all traffic gets routed on the private AWS network and to some endpoint (such as a load balancer or API Gateway) in a Region chosen by routing rules that are maintained within Global Accelerator. Compared with routing based on Route 53 rules, Global Accelerator request routing has lower latencies because it reduces the amount of traffic on the public internet. In addition, because Global Accelerator doesn’t depend on DNS TTL expiration to change routing rules, it can adjust routing more quickly. @@ -68 +59 @@ A client uses [AWS Global Accelerator](https://aws.amazon.com/global-accelerator - * With _write to your Region_ mode, it’s best to avoid Global Accelerator unless you're also using compute-layer request routing. + @@ -69,0 +61 @@ A client uses [AWS Global Accelerator](https://aws.amazon.com/global-accelerator +With _write to any Region_ mode, or if combined with the compute-layer request routing on the back- end, Global Accelerator works seamlessly. The client connects to the nearest edge location and need not be concerned with which Region receives the request. @@ -70,0 +63 @@ A client uses [AWS Global Accelerator](https://aws.amazon.com/global-accelerator +With _write to one Region_ Global Accelerator routing rules must send requests to the currently active Region. You can use health checks that artificially report a failure on any Region that’s not considered by your global system to be the active Region. As with DNS, it’s possible to use an alternative DNS domain name for routing read requests if the requests can be from any Region. @@ -71,0 +65 @@ A client uses [AWS Global Accelerator](https://aws.amazon.com/global-accelerator +With _write to your Region_ mode, it’s best to avoid Global Accelerator unless you're also using compute-layer request routing. @@ -81 +75 @@ Write modes -Evacuating a Region +Evacuation processes