DynamoDB RCU/WCU explained (with sizing examples)

DynamoDB pricing is often described as “RCU/WCU”, but the part that trips teams up is that units are not “one request equals one unit”. The effective units depend on item size, access pattern, and whether you scan or query targeted keys.

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.

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.

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

  1. Measure request volume (baseline + busy month).
  2. Measure item sizes (average and p95) for read and write paths.
  3. List GSIs and determine which write paths update them.
  4. 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.

Sources


Related guides


Related calculators


FAQ

Why does item size matter so much for DynamoDB cost?
Because read and write units are tied to how much data an operation processes. Larger items consume more units per request.
Are scans always expensive?
Scans can be expensive because they read many items to return a small subset. If you scan large ranges routinely, reads often dominate the bill.

Last updated: 2026-02-07