Provisioned capacity refers to the amount of RCU (read capacity units) and WCU (write capacity units) that is configured for your table or index. Writes to a table or index will be throttled if there is not enough WCU, and reads from a table will be throttled if there is not enough RCU. In most DynamoDB use cases, you will want to have at least 10% extra RCU and WCU so that your table or index can handle small bursts of traffic without throttling.


EFFECTS


Running above provisioned capacity can cause:

  • Throttled requests
  • Partial results returned from DynamoDB queries

 

QUICK FIX


If you are running at or above 100% capacity on reads or writes, you can alleviate throttling issues by increasing capacity slowly. Be aware of how partitioning in DynamoDB works, and realize that if your application is already consuming 100% capacity, it may take several capacity increases to figure out how much is needed. Increasing capacity by a large amount is not recommended, and may cause throttling issues due to how partitioning works in tables and indexes.

 

THOROUGH FIX


Start by understanding how your application uses DynamoDB. At your peak time, how many requests are going to each table or index? You can use this information to set your capacity statically, or to set up DynamoDB Auto Scaling.

Auto Scaling in DynamoDB uses Amazon Cloudwatch alarms to manage the capacity of the table or index. Handling throttled requests is important because auto scaling uses the amount of consumed capacity to determine how much provisioned capacity to add. This can be an issue because if you are throttling a lot, your consumed capacity is likely less than the amount you really need and it may take several auto scaling actions to get the system where it needs to be.

Auto scaling is recommended when:

  • Your application can handle periods of request throttling
  • Your application’s workload is not constant


RESOURCES


 Note: Our system uses DynamoDB metrics in Amazon CloudWatch to detect possible issues with DynamoDB. Due to the API limitations of CloudWatch, there can be a delay of as many as 20 minutes before our system can detect these issues.