DynamoDB Read Capacity Calculator
Calculate RCUs for a read workload including burst headroom and autoscaling target, and price provisioned against on-demand.
Inputs
RCUs to Provision
1,143RCU
RCUs Consumed at Peak
800RCU
Read Units per Operation
0.50
Provisioned Monthly Cost
$108.47
On-demand Monthly Cost
$131.40
Cheaper Capacity Mode
Provisioned with autoscaling — the load is steady enough to reserve
Step by step
Values used
Average read operations = 800 reads/s; Average item size = 3.50 KB; Read consistency = Eventually consistent — half an RCU per 4 KB; Peak to average ratio = 2 x; Autoscaling target utilisation = 70 %; Provisioned read capacity price = 0.0001 $/RCU-hour; Billed hours per month = 730 hours; On-demand read price = 0.1250 $/million read units
DynamoDB Read Capacity
units per read = ceil(item KB ÷ 4) × consistency factor; RCUs to provision = ceil(peak reads/s × units per read ÷ autoscaling target).
RCUs to Provision
= 1,143 RCU
RCUs Consumed at Peak
= 800 RCU
Read Units per Operation
= 0.50
Provisioned Monthly Cost
= 108.47
On-demand Monthly Cost
= 131.40
Cheaper Capacity Mode
= Provisioned with autoscaling — the load is steady enough to reserve
How it works
A read is billed in whole 4 KB blocks, so a 3.5 KB item and a 4 KB item cost the same while a 4.1 KB item costs twice as much. Provisioning must exceed the peak rather than the average, and because autoscaling chases a target utilisation the provisioned figure is the peak divided by that target — at 70% you reserve about 43% more capacity than the peak actually consumes. Both prices are editable inputs with realistic us-east-1 defaults — confirm the current DynamoDB rates with AWS for your region. Under-provisioned reads surface as throttling and retry storms in the client rather than as a slow query, so sizing on peak and a utilisation target is what keeps p99 latency flat.
Formula
DynamoDB Read Capacity
units per read = ceil(item KB ÷ 4) × consistency factor; RCUs to provision = ceil(peak reads/s × units per read ÷ autoscaling target).
- 4 KB
- Read unit block size — every read rounds up to a whole block
- consistency factor
- 0.5 eventual, 1 strong, 2 transactional
- peak to average
- Ratio of busiest second to the daily average
- autoscaling target
- Utilisation DynamoDB aims to hold, so provisioned sits above peak
Frequently Asked Questions
How is DynamoDB Read Capacity calculated?
units per read = ceil(item KB ÷ 4) × consistency factor; RCUs to provision = ceil(peak reads/s × units per read ÷ autoscaling target). A read is billed in whole 4 KB blocks, so a 3.5 KB item and a 4 KB item cost the same while a 4.1 KB item costs twice as much. Provisioning must exceed the peak rather than the average, and because autoscaling chases a target utilisation the provisioned figure is the peak divided by that target — at 70% you reserve about 43% more capacity than the peak actually consumes. Both prices are editable inputs with realistic us-east-1 defaults — confirm the current DynamoDB rates with AWS for your region.
Why does DynamoDB Read Capacity matter?
Under-provisioned reads surface as throttling and retry storms in the client rather than as a slow query, so sizing on peak and a utilisation target is what keeps p99 latency flat.
What values do I need to enter?
This calculator takes 8 inputs: Average read operations, Average item size, Read consistency, Peak to average ratio, Autoscaling target utilisation, Provisioned read capacity price, Billed hours per month, On-demand read price. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.
Should I use eventually consistent reads?
Wherever the application tolerates a few hundred milliseconds of staleness, yes — they cost half as much and are the default for Query and Scan. Use strongly consistent reads only for read-after-write paths, and remember they cannot be served from a global secondary index.