AWS amazondynamodb documentation change
Summary
Expanded documentation on handling DynamoDB throttling scenarios, clarified Auto Scaling limitations, added decision-making guidance for throttling responses, restructured mitigation strategies, and updated metric references.
Security assessment
The changes focus on operational best practices for capacity management and throttling mitigation. While throttling impacts availability, there is no evidence of addressing vulnerabilities, exploits, or security controls. The updates improve clarity about Auto Scaling behavior and capacity planning without introducing security-specific content.
Diff
diff --git a/amazondynamodb/latest/developerguide/throttling-provisioned-capacity-exceeded-mitigation.md b/amazondynamodb/latest/developerguide/throttling-provisioned-capacity-exceeded-mitigation.md index 2ce0c8e3f..fe7b42b69 100644 --- a//amazondynamodb/latest/developerguide/throttling-provisioned-capacity-exceeded-mitigation.md +++ b//amazondynamodb/latest/developerguide/throttling-provisioned-capacity-exceeded-mitigation.md @@ -9 +9,3 @@ Provisioned throughput exceeded mitigation measuresCommon diagnosis and monitori -Provisioned capacity throttling occurs when your application's consumption rate exceeds the read or write capacity units (RCUs/WCUs) configured for your tables or global secondary indexes. While DynamoDB provides burst capacity to handle occasional traffic spikes, sustained requests beyond your provisioned limits result in throttling. When this happens, DynamoDB returns a `ProvisionedThroughputExceeded` throttling reason type in the throttling exception. The reason identifies whether the issue is with read or write operations and whether it affects the base table or a global secondary index. Throttling can occur regardless of whether auto scaling is enabled. +Provisioned capacity throttling occurs when your application's consumption rate exceeds the read or write capacity units (RCUs/WCUs) configured for your tables or global secondary indexes. While DynamoDB provides burst capacity to handle occasional traffic spikes, sustained requests beyond your provisioned limits result in throttling. When this happens, DynamoDB returns a `ProvisionedThroughputExceeded` throttling reason type in the throttling exception. The reason identifies whether the issue is with read or write operations and whether it affects the base table or a global secondary index. + +Throttling can occur regardless of whether Auto Scaling is enabled. Auto Scaling adapts to increases in consumption, but it does not respond instantly and it is constrained by the maximum capacity limits you configure. This means throttling can still occur during sudden traffic spikes or when consumption exceeds your maximum Auto Scaling limits. @@ -15 +17,21 @@ This section provides resolution guidance for provisioned capacity throttling sc -Select a specific throttling reason below to find recommended mitigation options: +Before diving into specific throttling scenarios, first consider if the throttling is actually a problem that needs resolution: + + * Occasional throttling is normal and expected in well-optimized DynamoDB applications. Throttling simply means you're consuming 100% of what you've provisioned. If your application handles throttling gracefully with retries and your overall performance meets requirements, the throttling may not require immediate action. + + * However, if throttling is causing unacceptable client-side latency, degrading user experience, or preventing critical operations from completing in a timely manner, then proceed with the mitigation options below. + + + + +When you need to address throttling issues, first determine if your throttling is caused by: + + * **Temporary traffic spikes:** Short-duration increases in traffic that exceed your provisioned capacity but aren't sustained. These require different strategies than continuous high traffic. + + * **Continuous high traffic:** Sustained workloads that consistently exceed your provisioned capacity. + + + + +For traffic spikes, consider the strategies from the _Handle traffic spikes with Amazon DynamoDB provisioned capacity_ blog in Additional resources. + +For continuous high traffic, consider the capacity adjustment options below: @@ -36 +58 @@ Your application's read consumption rate exceeds the [provisioned read capacity -Choose the appropriate strategy based on your table's Auto Scaling configuration: +Consider these strategies to resolve read capacity throttling: @@ -38 +60 @@ Choose the appropriate strategy based on your table's Auto Scaling configuration - * Consider switching your table to on-demand capacity mode. + * **Switch to on-demand capacity mode:** Consider switching your table to on-demand if you experience frequent throttling from traffic spikes. On-demand eliminates provisioning concerns and automatically scales with your workload. @@ -40 +62 @@ Choose the appropriate strategy based on your table's Auto Scaling configuration - * **If Auto Scaling is not enabled:** + * **If staying with provisioned mode and Auto Scaling is not enabled:** @@ -61 +83 @@ Your application's write consumption rate exceeds the [provisioned write capacit -Choose the appropriate strategy based on your table's Auto Scaling configuration: +Consider these strategies to resolve write capacity throttling: @@ -63 +85 @@ Choose the appropriate strategy based on your table's Auto Scaling configuration - * Consider switching your table to on-demand capacity mode. + * **Switch to on-demand capacity mode:** Consider switching your table to on-demand if you experience frequent throttling from traffic spikes. On-demand eliminates provisioning concerns and automatically scales with your workload. @@ -65 +87 @@ Choose the appropriate strategy based on your table's Auto Scaling configuration - * **If Auto Scaling is not enabled:** + * **If staying with provisioned mode and Auto Scaling is not enabled:** @@ -73 +95 @@ Choose the appropriate strategy based on your table's Auto Scaling configuration - * Optimize your table's write auto-scaling parameters. + * Optimize your table's write Auto Scaling parameters. @@ -82 +104 @@ Choose the appropriate strategy based on your table's Auto Scaling configuration -Read requests to a Global Secondary Index (GSI) exceed the GSI's [provisioned read capacity units](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_ProvisionedThroughput.html#DDB-Type-ProvisionedThroughput-ReadCapacityUnits) (RCUs). You can monitor the CloudWatch metrics in Common diagnosis and monitoring to analyze your throttling event. +Read consumption on a Global Secondary Index (GSI) exceeds the GSI's [provisioned read capacity units](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_ProvisionedThroughput.html#DDB-Type-ProvisionedThroughput-ReadCapacityUnits) (RCUs). You can monitor the CloudWatch metrics in Common diagnosis and monitoring to analyze your throttling event. @@ -86 +108 @@ Read requests to a Global Secondary Index (GSI) exceed the GSI's [provisioned re -Choose the appropriate strategy based on your GSI's Auto Scaling configuration: +Consider these strategies to resolve GSI read capacity throttling: @@ -88 +110 @@ Choose the appropriate strategy based on your GSI's Auto Scaling configuration: - * Consider switching the base table to on-demand capacity mode. + * **Switch to on-demand capacity mode:** Consider switching the base table to on-demand if you experience frequent throttling from traffic spikes. On-demand eliminates provisioning concerns and automatically scales with your workload. @@ -90 +112 @@ Choose the appropriate strategy based on your GSI's Auto Scaling configuration: - * **If Auto Scaling is not enabled:** + * **If staying with provisioned mode and Auto Scaling is not enabled:** @@ -98 +120 @@ Choose the appropriate strategy based on your GSI's Auto Scaling configuration: - * Optimize your GSI's read auto-scaling parameters. + * Optimize your GSI's read Auto Scaling parameters. @@ -111 +133 @@ Updates to items in the base table trigger writes to a GSI that exceed the [GSI' -Choose the appropriate strategy based on your GSI's Auto Scaling configuration: +Consider these strategies to resolve GSI write capacity throttling: @@ -113 +135 @@ Choose the appropriate strategy based on your GSI's Auto Scaling configuration: - * Consider switching the base table to on-demand capacity mode. + * **Switch to on-demand capacity mode:** Consider switching the base table to on-demand if you experience frequent throttling from traffic spikes. On-demand eliminates provisioning concerns and automatically scales with your workload. @@ -115 +137 @@ Choose the appropriate strategy based on your GSI's Auto Scaling configuration: - * **If Auto Scaling is not enabled:** + * **If staying with provisioned mode and Auto Scaling is not enabled:** @@ -123 +145 @@ Choose the appropriate strategy based on your GSI's Auto Scaling configuration: - * Optimize your GSI's write auto-scaling parameters. + * Optimize your GSI's write Auto Scaling parameters. @@ -136,10 +158 @@ Monitor these key metrics to diagnose provisioned capacity throttling: - * **Throttling events:** `ReadProvisionedThroughputThrottleEvents` and `WriteProvisionedThroughputThrottleEvents` track when requests are throttled. [`ReadThrottleEvents`](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ReadThrottleEvents) and `WriteThrottleEvents` track when any read or write requests exceed the provisioned capacity. - - * **Capacity consumption:** [`ConsumedReadCapacityUnits`](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ConsumedReadCapacityUnits) and `ConsumedWriteCapacityUnits` show actual usage. - - * **Provisioned capacity:** `ProvisionedReadCapacityUnits` and `ProvisionedWriteCapacityUnits` show configured limits. - - - - -###### Analysis approach + * **Throttling events:** [`ReadProvisionedThroughputThrottleEvents`](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ReadProvisionedThroughputThrottleEvents) and [`WriteProvisionedThroughputThrottleEvents`](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#WriteProvisionedThroughputThrottleEvents) track when requests are throttled for this reason.[`ReadThrottleEvents`](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ReadThrottleEvents) and [`WriteThrottleEvents`](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#WriteThrottleEvents) track when any read or write requests exceed the provisioned capacity. @@ -147 +160 @@ Monitor these key metrics to diagnose provisioned capacity throttling: -Follow these steps to confirm throttling diagnosis: + * **Capacity consumption:** [`ConsumedReadCapacityUnits`](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ConsumedReadCapacityUnits) and [`ConsumedWriteCapacityUnits`](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ConsumedWriteCapacityUnits) show actual usage. @@ -149 +162 @@ Follow these steps to confirm throttling diagnosis: - 1. Compare consumed capacity to provisioned capacity - if consumption consistently approaches or exceeds provisioned limits, this confirms the diagnosis. + * **Provisioned capacity:** [`ProvisionedReadCapacityUnits`](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ProvisionedReadCapacityUnits) and [`ProvisionedWriteCapacityUnits`](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ProvisionedWriteCapacityUnits) show configured limits. @@ -151 +163,0 @@ Follow these steps to confirm throttling diagnosis: - 2. Review throttling event frequency and timing to identify patterns. @@ -153 +164,0 @@ Follow these steps to confirm throttling diagnosis: - 3. Use [CloudWatch Contributor Insights](./contributorinsights_HowItWorks.html) to identify which items or partition keys consume the most capacity. @@ -156,4 +166,0 @@ Follow these steps to confirm throttling diagnosis: - - -For an overview of how to evaluate if you have right-sized provisioning on your DynamoDB tables, see [Evaluate your provisioned capacity for right-sized provisioning in your DynamoDB table](./CostOptimization_RightSizedProvisioning.html). - @@ -172 +179 @@ Use this procedure when Auto Scaling is not enabled and you need immediate capac - 2. Ensure that your table's provisioned throughput capacity remains within the [ per-account and per-table throughput limit in your Region.](./ServiceQuotas.html). + 2. Verify that your new capacity settings don't exceed the [per-table throughput quotas](./ServiceQuotas.html) and that your total account consumption remains below the [per-account throughput quotas](./ServiceQuotas.html) for your Region. If you're approaching these limits, consider switching to on-demand capacity mode instead. @@ -198,2 +204,0 @@ Lower target utilization increases costs and scaling frequency. Targets below 40 -For predictable traffic patterns and planned events, Application Auto Scaling supports scheduled scaling actions for DynamoDB tables. These scheduled actions allow you to adjust the read or write capacity of your tables at predetermined times using cron expressions. - @@ -204 +209 @@ For guidance on configuring and managing DynamoDB Auto Scaling, see [Managing th -Be aware that Auto Scaling has some latency and may not react quickly enough to sudden traffic spikes, which is why proper target utilization settings with adequate headroom are important. +Auto Scaling typically takes several minutes to respond to traffic changes. For sudden traffic spikes, your table's burst capacity provides immediate protection while Auto Scaling adjusts. Configure target utilization with adequate headroom to allow time for scaling operations and to preserve burst capacity for unexpected demand. @@ -208 +213 @@ Be aware that Auto Scaling has some latency and may not react quickly enough to -Use this procedure when [Auto Scaling](./AutoScaling.html) is enabled but throttling still occurs. You can tune auto-scaling independently for both tables and global secondary indexes (GSIs), with separate controls for read and write capacity units. +Use this procedure when [Auto Scaling](./AutoScaling.html) is enabled but throttling still occurs. You can tune Auto Scaling independently for both tables and global secondary indexes (GSIs), with separate controls for read and write capacity units. @@ -214,2 +218,0 @@ Use this procedure when [Auto Scaling](./AutoScaling.html) is enabled but thrott - * **Modify scaling policies:** Modify your scaling policies to be more aggressive for workloads with rapid changes in demand. - @@ -240,3 +243 @@ Use this procedure when Auto Scaling is not enabled on your GSI or you need imme - * For detailed information about handling traffic spikes in DynamoDB provisioned capacity tables, including various strategies from utilizing auto scaling and burst capacity to strategic throttle management, see [Handle traffic spikes with Amazon DynamoDB provisioned capacity](https://aws.amazon.com/blogs/). - - * For detailed strategies on optimizing Auto Scaling configurations and performance tuning, see [DynamoDB Auto Scaling: Performance and cost optimization at any scale](https://aws.amazon.com/blogs/database/amazon-dynamodb-auto-scaling-performance-and-cost-optimization-at-any-scale/). + * For detailed information about handling traffic spikes in DynamoDB provisioned capacity tables, including various strategies from utilizing Auto Scaling and burst capacity to strategic throttle management, see [Handle traffic spikes with Amazon DynamoDB provisioned capacity](https://aws.amazon.com/blogs/database/handle-traffic-spikes-with-amazon-dynamodb-provisioned-capacity/).