AWS amazondynamodb documentation change
Summary
Updated global tables documentation with details on MRSC/MREC consistency modes, monitoring guidance, pricing clarifications, region support restrictions, replication behavior, transaction limitations, backup strategies, and CloudFormation best practices.
Security assessment
The changes emphasize detecting IAM configuration errors in health checks (a security best practice) and clarify region compliance considerations. While these improve security awareness, there is no direct evidence of addressing a specific vulnerability.
Diff
diff --git a/amazondynamodb/latest/developerguide/bp-global-table-design.prescriptive-guidance.checklist-and-faq.md b/amazondynamodb/latest/developerguide/bp-global-table-design.prescriptive-guidance.checklist-and-faq.md index 824e0b1fc..939f6a3a1 100644 --- a//amazondynamodb/latest/developerguide/bp-global-table-design.prescriptive-guidance.checklist-and-faq.md +++ b//amazondynamodb/latest/developerguide/bp-global-table-design.prescriptive-guidance.checklist-and-faq.md @@ -7 +7 @@ FAQ -# Preparation checklist for DynamoDB global tables and Frequently Asked Questions +# Preparation checklist for DynamoDB global tables @@ -11 +11 @@ Use the following checklist for decisions and tasks when you deploy global table - * Determine how many and which Regions should participate in the global table. + * Determine if your use case benefits more from an MRSC or MREC consistency mode. Do you need strong consistency, even with the higher latency and other tradeoffs? @@ -13 +13 @@ Use the following checklist for decisions and tasks when you deploy global table - * Determine your application’s write mode. For more information, see [Write modes with DynamoDB global tables](./bp-global-table-design.prescriptive-guidance.writemodes.html). + * Determine how many and which Regions should participate in the global table. If you plan to use MRSC, decide if you want the third Region to be a replica or a witness. @@ -15 +15 @@ Use the following checklist for decisions and tasks when you deploy global table - * Plan your [Request routing with DynamoDB global tables](./bp-global-table-design.prescriptive-guidance.request-routing.html) strategy, based on your write mode. + * Determine your application’s write mode. This is not the same as the consistency mode. For more information, see [Write modes with DynamoDB global tables](./bp-global-table-design.prescriptive-guidance.writemodes.html). @@ -17 +17,3 @@ Use the following checklist for decisions and tasks when you deploy global table - * Define your [](./bp-global-table-design.prescriptive-guidance.evacuation.html#bp-global-table-design.prescriptive-guidance.evacuation.title) evacuation plan, based on your write mode and routing strategy. + * Plan your [Routing strategies in DynamoDB](./bp-global-table-design.prescriptive-guidance.request-routing.html) strategy, based on your write mode. + + * Define your [](./bp-global-table-design.prescriptive-guidance.evacuation.html#bp-global-table-design.prescriptive-guidance.evacuation.title) [Evacuation processes](./bp-global-table-design.prescriptive-guidance.evacuation.html), based on your consistency mode, write mode, and routing strategy. @@ -21 +23 @@ Use the following checklist for decisions and tasks when you deploy global table - * Set alarms for any sustained increase in `ReplicationLatency`. An increase might indicate an accidental misconfiguration in which the global table has different write settings in different Regions, which leads to failed replicated requests and increased latencies. It could also indicate that there is a Regional disruption. A [good example](https://aws.amazon.com/blogs/database/monitoring-amazon-dynamodb-for-operational-awareness/) is to generate an alert if the recent average exceeds 180,000 milliseconds. You might also watch for `ReplicationLatency` dropping to 0, which indicates stalled replication. + * If you're using MREC, set alarms for any sustained increase in `ReplicationLatency`. An increase might indicate an accidental misconfiguration in which the global table has different write settings in different Regions, which leads to failed replicated requests and increased latencies. It could also indicate that there is a Regional disruption. A [good example](https://aws.amazon.com/blogs/database/monitoring-amazon-dynamodb-for-operational-awareness/) is to generate an alert if the recent average exceeds 180,000 milliseconds. You might also watch for `ReplicationLatency` dropping to 0, which indicates stalled replication. @@ -31 +33 @@ Use the following checklist for decisions and tasks when you deploy global table -It’s best practice to rely only on data plane operations and not control plane operations because some control plane operations may be degraded during region failures. +With failover procedures, it's best practice to rely only on data plane operations and not on control plane operations, because some control plane operations could be degraded during Region failures. @@ -37 +39 @@ For more information, see the AWS blog post [ Build resilient applications with - * Consider using Resilience Hub to evaluate the resilience of your entire application (including global tables). It provides a comprehensive view of your overall application portfolio resilience status through its dashboard. + * Consider using [AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html) to evaluate the resilience of your entire application (including global tables). It provides a comprehensive view of your overall application portfolio resilience status through its dashboard. @@ -41 +43 @@ For more information, see the AWS blog post [ Build resilient applications with - * When writing a health check for use with Route 53 or Global Accelerator, it’s not sufficient to just ping that the DynamoDB endpoint is up. That doesn’t cover the many failure modes such as IAM configuration errors, code deployment problems, failure in the stack outside DynamoDB, higher than average read or write latencies, and so on. It’s best to perform a set of calls that exercise a full database flow. + * When you write health checks for use with Route 53 or Global Accelerator, make a set of calls that cover the full database flow. If you limit your check to confirm only that the DynamoDB endpoint is up, you won’t be able to cover many failure modes such as AWS Identity and Access Management (IAM) configuration errors, code deployment problems, failure in the stack outside DynamoDB, higher than average read or write latencies, and so on. @@ -48 +50 @@ For more information, see the AWS blog post [ Build resilient applications with -**What are some useful principles for overall usage of DynamoDB global tables?** +**What is the pricing for global tables?** @@ -50 +52 @@ For more information, see the AWS blog post [ Build resilient applications with -DynamoDB global tables has very few control knobs yet still requires a number of considerations. 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 data set with low-latency reads and writes and a 99.999% service level agreement. + * A write operation in a traditional DynamoDB table is priced in write capacity units (WCUs, for provisioned tables) or write request units (WRUs) for on-demand tables. If you write a 5 KB item, it incurs a charge of 5 units. A write to a global table is priced in replicated write capacity units (rWCUs, for provisioned tables) or replicated write request units (rWRUs, for on-demand tables). rWCUs and rWRUs are priced the same as WGUs and WRUs. @@ -52 +54 @@ DynamoDB global tables has very few control knobs yet still requires a number of -**What is the pricing for global tables?** + * rWCU and rWRU changes are incurred in every Region where the item is written directly or written through replication. Cross-Region data transfer fees apply. @@ -54 +56 @@ DynamoDB global tables has very few control knobs yet still requires a number of -A write to a traditional DynamoDB table is priced in Write Capacity Units (WCUs, for provisioned tables) or Write Request Units (WRUs, for on-demand tables). If you write a 5 KB item it incurs a charge of 5 units. A write to a global table is priced in Replicated Write Capacity Units (rWCUs, for provisioned tables) or Replicated Write Request Units (rWRUs, for on-demand tables). + * Writing to a global secondary index (GSI) is considered a local write operation and uses regular write units. @@ -56 +58 @@ A write to a traditional DynamoDB table is priced in Write Capacity Units (WCUs, -The rWCUs and rWRUs include the cost of the streaming infrastructure needed to manage the replication. + * There is no reserved capacity available for rWCUs or rWRUs at this time. Purchasing reserved capacity for WCUs can be beneficial for tables where GSIs consume write units. @@ -58 +60 @@ The rWCUs and rWRUs include the cost of the streaming infrastructure needed to m -Replicated Write Unit charges are incurred in every Region where the item is directly written or replicate written. + * When you add a new Region to a global table, DynamoDB bootstraps the new Region automatically and charges you as if it were a table restore, based on the GB size of the table. It also charges cross-Region data transfer fees. @@ -60 +61,0 @@ Replicated Write Unit charges are incurred in every Region where the item is dir -Writing to a Global Secondary Index (GSI) is considered a local write and uses regular Write Units. @@ -62 +62,0 @@ Writing to a Global Secondary Index (GSI) is considered a local write and uses r -There is no Reserved Capacity available for rWCUs at this time. Purchasing Reserved Capacity may still be beneficial for tables with GSIs consuming write units. @@ -64 +63,0 @@ There is no Reserved Capacity available for rWCUs at this time. Purchasing Reser -The initial bootstrap when adding a new Region to a global table is charged like a restore per GB of data restored, plus cross-Region data transfer fees. @@ -68 +67,10 @@ The initial bootstrap when adding a new Region to a global table is charged like -[Global Tables version 2019.11.21 (Current)](./GlobalTables.html) is available in all Regions. +[Global Tables version 2019.11.21 (Current)](./GlobalTables.html) supports all AWS Regions for MREC tables and the following Region sets for MRSC tables: + + * US Region set: US East (N.Virginia), US East (Ohio), US West (Oregon) + + * EU Region set: Europe (Ireland), Europe (London), Europe (Paris), Europe (Frankfort) + + * AP Region set: Asia Pacific (Tokyo), Asia Pacific (Seoul), and Asia Pacific (Osaka) + + + @@ -76 +84,6 @@ In [Global Tables version 2019.11.21 (Current)](./GlobalTables.html), when you c -You can delete a replica table the same way you would delete any other table. Deleting the global table stops replication to that Region and deletes the table copy kept in that Region. However, you cannot stop replication while keeping copies of the table as independent entities, nor can you pause replication. + * You can delete a replica table the same way you would delete any other table. Deleting the global table stops replication to that Region and deletes the table copy kept in that Region. However, you can't stop replication while keeping copies of the table as independent entities, nor can you pause replication. + + * An MRSC table must be deployed in exactly three Regions. To delete the replicas you must delete all the replicas and the witness so that the MRSC table becomes a local table. + + + @@ -80 +93,8 @@ You can delete a replica table the same way you would delete any other table. De -Each global table produces an independent stream based on all its writes, wherever they started from. You can choose to consume the DynamoDB stream in one Region or in all Regions (independently). If you want to process local but not replicated write operations, you can add your own Region attribute to each item to identify the writing Region. You can then use a Lambda event filter to call the Lambda function only for write operations in the local Region. This helps with insert and update operations, but unfortunately not delete operations. + * Each global table produces an independent stream based on all its write operations, wherever they started from. You can choose to consume the DynamoDB stream in one Region or in all Regions (independently). If you want to process local but not replicated write operations, you can add your own Region attribute to each item to identify the writing Region. You can then use a Lambda event filter to call the Lambda function only for write operations in the local Region. This helps with insert and update operations, but not delete operations. + + * Global tables that are configured for multi-Region eventual consistency (MREC tables) replicate changes by reading those changes from a DynamoDB stream on a replica table and applying that change to all other replica tables. Therefore, DynamoDB is enabled by default on all replicas in an MREC global table and cannot be disabled on those replicas. The MREC replication process can combine multiple changes in a short period of time into a single replicated write operation. As a result, each replica's stream might contain slightly different records. DynamoDB Streams records on MREC replicas are always ordered on a per-item basis, but ordering between items might differ between replicas. + + * Global tables that are configured for multi-Region strong consistency (MRSC tables) don’t use DynamoDB Streams for replication, so this feature isn’t enabled by default on MRSC replicas. You can enable DynamoDB Streams on an MRSC replica. DynamoDB Streams records on MRSC replicas are identical for every replica and are always ordered on a per-item basis, but ordering between items might differ between replicas. + + + @@ -84 +104,6 @@ Each global table produces an independent stream based on all its writes, wherev -Transactional operations provide atomicity, consistency, isolation, and durability (ACID) guarantees only within the Region where the write operation originally occurred. Transactions are not supported across Regions in global tables. For example, if you have a global table with replicas in the US East (Ohio) and US West (Oregon) Regions and perform a `TransactWriteItems` operation in the US East (Ohio) Region, you might observe partially completed transactions in the US West (Oregon) Region as changes are replicated. Changes are replicated to other Regions only after they have been committed in the source Region. + * Transactional operations on MRSC tables will generate errors. + + * Transactional operations on MREC tables provide atomicity, consistency, isolation, and durability (ACID) guarantees only within the Region where the write operation originally occurred. Transactions are not supported across Regions in global tables. For example, if you have an MREC global table with replicas in the US East (Ohio) and US West (Oregon) Regions and perform a `TransactWriteItems` operation in the US East (Ohio) Region, you might observe partially completed transactions in the US West (Oregon) Region as changes are replicated. Changes are replicated to other Regions only after they have been committed in the source Region. + + + @@ -96 +121,10 @@ No, tags do not automatically propagate. -The answer depends on the purpose of the backup. If you want to ensure data durability, DynamoDB already provides that safeguard. The service ensures durability. If you want to keep a snapshot for historical records (for example, to meet regulatory requirements), backing up in one Region should suffice. You can copy the backup to additional Regions by using AWS Backup. If you want to recover erroneously deleted or modified data, use [DynamoDB point-in-time recovery (PITR)](./PointInTimeRecovery_Howitworks.html) in one Region. +The answer depends on the purpose of the backup. + + * If you want to ensure data durability, DynamoDB already provides that safeguard. The service ensures durability. + + * If you want to keep a snapshot for historical records (for example, to meet regulatory requirements), backing up in one Region should suffice. You can copy the backup to additional Regions by using AWS Backup. + + * If you want to recover erroneously deleted or modified data, use [DynamoDB point-in-time recovery (PITR)](./PointInTimeRecovery_Howitworks.html) in one Region. + + + @@ -100 +134,7 @@ The answer depends on the purpose of the backup. If you want to ensure data dura -CloudFormation represents a DynamoDB table and a global table as two separate resources: `AWS::DynamoDB::Table` and `AWS::DynamoDB::GlobalTable`. One approach is to create all tables that can potentially be global by using the `GlobalTable` construct. You can then keep them as standalone tables initially, and add Regions later if needed. + * CloudFormation represents a DynamoDB table and a global table as two separate resources: `AWS::DynamoDB::Table` and `AWS::DynamoDB::GlobalTable`. One approach is to create all tables that can potentially be global by using the `GlobalTable` construct of keeping them as standalone tables initially, and add Regions later if necessary. + + * In CloudFormation, each global table is controlled by a single stack, in a single Region, regardless of the number of replicas. When you deploy your template, CloudFormation creates and updates all replicas as part of a single stack operation. You should not deploy the same [AWS::DynamoDB::GlobalTable](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-dynamodb-globaltable.html) resource in multiple Regions. This will result in errors and is unsupported. If you deploy your application template in multiple Regions, you can use conditions to create the `AWS::DynamoDB::GlobalTable` resource in a single Region. Alternatively, you can choose to define your `AWS::DynamoDB::GlobalTable` resources in a stack that’s separate from your application stack, and make sure that it’s deployed to a single Region. + + * If you have a regular table and you want to convert it to a global table while keeping it managed by CloudFormation then set the deletion policy to `Retain`, remove the table from the stack, convert the table to a global table in the console, and then import the global table as a new resource to the stack. For more information, see the [AWS GitHub repository](https://github.com/aws-samples/amazon-dynamodb-table-to-global-table-cdk). + + * Cross-account replication is not supported at this time. @@ -102 +141,0 @@ CloudFormation represents a DynamoDB table and a global table as two separate re -In CloudFormation, each global table is controlled by a single stack, in a single Region, regardless of the number of replicas. When you deploy your template, CloudFormation creates and updates all replicas as part of a single stack operation. You should not deploy the same [AWS::DynamoDB::GlobalTable](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-dynamodb-globaltable.html) resource in multiple Regions. This will result in errors and is unsupported. If you deploy your application template in multiple Regions, you can use conditions to create the `AWS::DynamoDB::GlobalTable` resource in a single Region. Alternatively, you can choose to define your `AWS::DynamoDB::GlobalTable` resources in a stack that’s separate from your application stack, and make sure that it’s deployed to a single Region. @@ -104 +142,0 @@ In CloudFormation, each global table is controlled by a single stack, in a singl -If you have a regular table and you want to convert it to a global table while keeping it managed by CloudFormation then set the deletion policy to Retain, remove the table from the stack, convert the table to a global table in the console, and then import the global table as a new resource to the stack. @@ -106 +143,0 @@ If you have a regular table and you want to convert it to a global table while k -Cross-account replication is not supported at this time. @@ -114 +151 @@ To use the Amazon Web Services Documentation, Javascript must be enabled. Please -Throughput capacity with global tables +Throughput capacity planning