DynamoDB Read Capacity Calculator
Calculate RCUs for a read workload including burst headroom and autoscaling target, and price provisioned against on-demand.
About DynamoDB Read Capacity Calculator
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
Worked example
With the default values below, DynamoDB Read Capacity Calculator returns RCUs to Provision of 1,143. Change any input above and every figure here is recalculated in your browser.
Inputs used
- Average read operationsaccepts 0–5,000,000 reads/s
- 800 reads/s
- Average item sizeaccepts 0.1–400 KB
- 3.5 KB
- Read consistencyone of Eventually consistent — half an RCU per 4 KB, Strongly consistent — one RCU per 4 KB, Transactional — two RCUs per 4 KB
- Eventually consistent — half an RCU per 4 KB
- Peak to average ratioaccepts 1–20 x
- 2 x
- Autoscaling target utilisationaccepts 20–100 %
- 70 %
- Provisioned read capacity priceminimum 0 $/RCU-hour
- 0.00013 $/RCU-hour
- Billed hours per monthaccepts 0–744 hours
- 730 hours
- On-demand read priceminimum 0 $/million read units
- 0.125 $/million read units
Results
- 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
Step by step
- 1Values used
- 2DynamoDB Read Capacity
- 3RCUs to Provision= 1,143 RCU
- 4RCUs Consumed at Peak= 800 RCU
- 5Read Units per Operation= 0.50
- 6Provisioned Monthly Cost= 108.47
- 7On-demand Monthly Cost= 131.40
- 8Cheaper Capacity Mode= Provisioned with autoscaling — the load is steady enough to reserve
Assumptions and limits
- The result is derived only from the 8 inputs listed above. Anything not among them is not part of the calculation.
- In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
- Figures are rounded for display to 2 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.
How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.
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.