DynamoDB pricing: what to model (reads, writes, storage, extras)

DynamoDB pricing is easiest when you model it as a few buckets: reads, writes, storage, and extras. Most estimation errors come from ignoring item size effects or forgetting secondary indexes and replication features.

1) Reads and writes: count the billable units

Request volume: reads/day and writes/day (or requests/second by workload type).
Item size: larger items consume more units per operation.
Access pattern: strongly consistent reads, scans, and transactional ops can cost more.

Related: RCU/WCU explained.

DynamoDB cost calculator RPS to requests

2) Storage: GB-month and data shape

Table storage: GB-month based on item size and item count.
Indexes: global secondary indexes (GSIs) can multiply stored bytes.
Retention policies: TTL and archival strategies reduce long-term storage growth.

How to estimate item size (so the model matches reality)

Measure average and p95 item size from real items (not just schema guesses).
Separate "hot path" items from "cold path" items (their sizes can differ significantly).
Estimate index storage separately: projected attributes often create an extra copy of data.

If you cannot measure yet, build a conservative range and validate as soon as you have real table data.

3) Common extras (do not forget these)

Backups / PITR: continuous backup and restore requirements can add a meaningful baseline.
Streams: if enabled, include downstream processing and storage.
Global tables: replication can add write/transfer/storage effects across regions.

Provisioned vs on-demand (what changes in the estimate)

Provisioned: model sustained capacity (and autoscaling behavior) and include headroom for busy months.
On-demand: model request volume and include incident multipliers (retries increase cost).
For either mode, item size and index amplification still matter.

A fast estimation workflow

Measure read and write request volume (baseline + busy month).
Measure typical item sizes (average and p95).
Model indexes (how many and what attributes they project).
Add extras: backups/PITR, streams, replication.

Common pitfalls

Using “requests” without converting to RCU/WCU based on item size and consistency.
Ignoring scans and large responses (they can dominate read units).
Forgetting that GSIs add storage and write amplification.
Modeling only steady state and ignoring incident retry storms.

Validation checklist

Validate request counts from a real week of usage (not only peak RPS).
Validate item sizes from real items (average and p95).
Validate index count and projections; treat them as separate storage/write multipliers.
Validate whether you require PITR, streams, or multi-region replication.