AWS amazondynamodb documentation change
Summary
Expanded documentation on AWS FIS integration for both MREC and MRSC global tables, added details about fault injection experiments, and restructured content about capacity management in provisioned/on-demand modes.
Security assessment
The changes focus on resilience testing and operational capacity management without addressing vulnerabilities. The AWS FIS integration helps validate application resilience but doesn't document security fixes or vulnerabilities.
Diff
diff --git a/amazondynamodb/latest/developerguide/V2globaltables_HowItWorks.md b/amazondynamodb/latest/developerguide/V2globaltables_HowItWorks.md index c89bf0268..0d0932ba4 100644 --- a//amazondynamodb/latest/developerguide/V2globaltables_HowItWorks.md +++ b//amazondynamodb/latest/developerguide/V2globaltables_HowItWorks.md @@ -124 +124,20 @@ Global tables configured for multi-Region strong consistency (MRSC) do not publi -MREC global tables integrate with the [AWS Fault Injection Service](https://docs.aws.amazon.com/resilience-hub/latest/userguide/testing.html) (AWS FIS) for performing fault injection experiments on your global table workloads. This enables you to test your application's response to a simulated Region isolation by pausing replication to and from a selected replica. For more information, see [ pausing global table replication](https://docs.aws.amazon.com/fis/latest/userguide/fis-actions-reference.html#dynamodb-actions-reference). +Both MREC and MRSC global tables integrate with [AWS Fault Injection Service](https://docs.aws.amazon.com/resilience-hub/latest/userguide/testing.html) (AWS FIS), a fully managed service for running controlled fault injection experiments to improve an application's resilience. Using AWS FIS, you can: + + * Create experiment templates that define specific failure scenarios. + + * Inject failures to validate application resilience by simulating Region isolation (that is, pausing replication to and from a selected replica) to test error handling, recovery mechanisms, and multi-Region traffic shift behavior when one AWS Region experiences disruption. + + + + +For example, in a global table with replicas in US East (N. Virginia), US East (Ohio), and US West (Oregon), you can run an experiment in US East (Ohio) to test region isolation there while US East (N. Virginia) and US West (Oregon) continue normal operations. This controlled testing helps you identify and resolve potential issues before they affect production workloads. + +See [ Action targets](https://docs.aws.amazon.com/fis/latest/userguide/action-sequence.html#action-targets) in the _AWS FIS user guide_ for a complete list of AWS FIS supported actions and [ Cross-Region Connectivity](https://docs.aws.amazon.com/fis/latest/userguide/cross-region-scenario.html) to pause DynamoDB replication between regions. + +For information about Amazon DynamoDB global table actions available in AWS FIS, see [DynamoDB global tables actions reference](https://docs.aws.amazon.com/fis/latest/userguide/fis-actions-reference.html#dynamodb-actions-reference) in the _AWS FIS User Guide_. + +To get started running fault injection experiments, see [Planning your AWS FIS experiments](https://docs.aws.amazon.com/fis/latest/userguide/getting-started-planning.html) in the AWS FIS user guide. + +###### Note + +During AWS FIS experiments in MRSC, eventually consistent reads are permitted, but table setting updates - such as changing billing mode or configuring table throughput - are not allowed, similar to MREC. Please check the CloudWatch metric [FaultInjectionServiceInducedErrors](./metrics-dimensions.html#FaultInjectionServiceInducedErrors) for additional details regarding the error code. @@ -152 +171,7 @@ Global tables configured for multi-Region strong consistency (MRSC) do not suppo -Replication consumes write capacity. Replicas configured for provisioned capacity may throttle requests if the combination of write throughput and replication throughput is higher than the provisioned write capacity. Write capacity in on-demand mode is synchronized for all replicas in a global table. Global tables configured for provisioned capacity synchronize auto scaling settings between replicas. The actual provisioned write capacity setting may vary between replicas according to consumed write throughput. +### Provisioned mode + +Replication consumes write capacity. Replicas configured for provisioned capacity may throttle requests if the combination of application write throughput and replication write throughput exceeds the provisioned write capacity. For global tables using provisioned mode, auto scaling settings for both read and write capacities are synchronized between replicas. + +You can independently configure read capacity settings for each replica in a global table by using the [`ProvisionedThroughputOverride`](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_ProvisionedThroughputOverride.html) parameter at the replica level. By default, changes to provisioned read capacity are applied to all replicas in the global table. When adding a new replica to a global table, the read capacity of the source table or replica is used as the initial value unless a replica-level override is explicitly specified. + +### On-demand mode @@ -154 +179 @@ Replication consumes write capacity. Replicas configured for provisioned capacit -You can independently configure read capacity settings for each replica in a global table. When adding a replica to a global table, the read capacity of the source table or replica is used as the initial value unless an override value is specified. +For global tables configured for on-demand mode, write capacity is automatically synchronized across all replicas. DynamoDB automatically adjusts capacity based on traffic, and there are no replica-specific read or write capacity settings to manage.