Provisioned mode is a DynamoDB capacity mode in which you configure a table’s read and write throughput in advance. You may enable autoscaling to adjust that provisioned capacity as load changes. section 12.11
Configure read and write capacity separately, in units consumed per second. Eventually consistent reads consume half the capacity of strongly consistent reads; item size determines the required units. section 12.11.1
Use these rules when sizing provisioned capacity:
- Allocate one write capacity unit per 1 KB of item size, rounding up for larger items. section 12.11.1
- Allocate one read capacity unit per strongly consistent 4 KB, rounding up for getItem operations. section 12.11.1
- Expect throttling when requests exceed provisioned throughput; substantially higher demand can cause DynamoDB to reject requests. section 12.11.1
- Increase throughput whenever needed, but treat decreases as constrained during a UTC day. section 12.11.1
Steady traffic with a batch spike
An application normally handles 100 reads and 10 writes per second from 9 a.m. to 5 p.m., but a batch job raises demand to 1,000 reads and 100 writes per second for the final hour. Provisioned mode requires capacity for the peak unless capacity changes or autoscaling accommodate the spike. On-demand mode may be more economical when traffic varies substantially. section 12.11
Table 12.1 Comparing pricing of DynamoDB on-demand and provisioned mode (view table figure)
Compare the illustrated monthly prices for on-demand and provisioned capacity at fixed read and write rates. section 12.11
$ aws dynamodb get-item --table-name todo-user \ --key '{"uid": {"S": "emma"}}' \ --return-consumed-capacity TOTAL \ #1 --query "ConsumedCapacity" { "CapacityUnits": 0.5, #2 "TableName": "todo-user" } $ aws dynamodb get-item --table-name todo-user \ --key '{"uid": {"S": "emma"}}' \ --consistent-read --return-consumed-capacity TOTAL \ #3 --query "ConsumedCapacity" { "CapacityUnits": 1.0, #4 "TableName": "todo-user" } #1 Tells DynamoDB to return the used capacity units #2 getItem requires 0.5 capacity units. #3 A consistent read ... #4 ... needs twice as many capacity units.
Inspect CLI results showing that an eventually consistent getItem consumes 0.5 capacity units while a strongly consistent read consumes 1.0. section 12.11.1
