DynamoDB RCU/WCU explained (with sizing examples)

Reviewed by CloudCostKit Editorial Team. Last updated: 2026-02-07. Editorial policy and methodology.

Start with a calculator if you need a first-pass estimate, then use this guide to validate the assumptions and catch the billing traps.

RPS to Monthly Requests Calculator API Request Cost Calculator CDN Request Cost Calculator

This page is the capacity-measurement explainer, not the bill-boundary page: the goal is to turn item size, consistency, query shape, scan behavior, and index updates into a defendable read and write unit model.

If you are still deciding which costs belong inside the DynamoDB bill versus beside it, go back to the pricing guide first.

Evidence pack before you size anything

Item size: average and p95 item sizes for the read and write paths that matter.
Consistency: where strong reads, transactional patterns, or other higher-cost behaviors are used.
Query shape: which paths are targeted queries versus broad or exploratory reads.
Scan behavior: where scans still exist and how much hidden read exposure they create.
Index updates: which write paths also update GSIs or replicated copies.

RCU/WCU quick sizing

Item size: larger items consume more units.
Read/write rate: baseline requests per second.
Consistency: strong reads consume more RCUs.

Step 1: define what you need to size

Reads: requests/second and average item size returned (plus worst-case ranges).
Writes: writes/second and average item size written.
Extras: GSIs and transactional operations can change effective units.

DynamoDB cost calculator DynamoDB pricing

Step 2: the “item size multiplier” intuition

If you double the item size, you often increase the consumed capacity per operation. This is why data shape changes can change the bill without any traffic change.

Small items: per-request units are closer to the minimum.
Large items: per-request units increase; scans become especially expensive.
Indexes: writing one item can mean writing multiple index entries.

Separate raw request counts from billable unit exposure

Raw request counts: useful as a starting point, but not enough to price DynamoDB accurately.
Unit exposure: requests after size, consistency, scan behavior, and index amplification are applied.
Busy-window exposure: incident retries, scans, and hot partitions can move billable units much faster than traffic averages suggest.
Write-path exposure: one logical write may update multiple indexes or replicas, so the billable unit story is larger than one API call.

Step 3: sizing examples (planning)

Treat these as workflow examples, not exact pricing rules. Always validate with official pricing and measured consumption for your table.

Example A (reads): 200 read requests/second, small items, mostly key queries -> reads dominate by request volume.
Example B (writes): 50 write requests/second, large items, multiple indexes -> writes dominate due to amplification.
Example C (scan trap): “find recent failures” implemented as a scan -> reads dominate because you read many items to return a few.

How to estimate in practice

Measure request volume (baseline + busy month).
Measure item sizes (average and p95) for read and write paths.
List GSIs and determine which write paths update them.
Identify scans and replace with key-based queries where possible.

Common pitfalls

Assuming one request equals one unit (item size changes it).
Forgetting that GSIs add write amplification and storage copies.
Ignoring retries/timeouts that multiply requests during incidents.
Using scans for user-facing traffic or dashboards.

Validation checklist

Validate item size distribution (average and p95) from real items.
Validate what percent of reads are scans vs queries.
Validate GSI count and projections; quantify amplification.
After changes, compare a real week of usage and adjust your model.

When the unit model is ready to hand off

Go back to DynamoDB pricing if you still are not sure which costs belong inside the bill versus beside it.
Move to DynamoDB cost optimization when you can defend whether reads, writes, storage, or index amplification is the dominant driver.