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

Reviewed by CloudCostKit Editorial Team. Last updated: 2026-01-27. Editorial policy and methodology.

Use this page when you need to decide what belongs inside the DynamoDB bill before you debate schema changes, caching, or retry control.

This guide is about bill boundaries: read exposure, write exposure, table storage, index amplification, backups, streams, global tables, and the adjacent cache, stream-consumer, or application-side costs that should be tracked beside the DynamoDB bill rather than blended into it.

Inside the DynamoDB bill vs beside the DynamoDB bill

Inside the DynamoDB bill: read exposure, write exposure, table storage, and GSI-driven amplification.
Also inside the DynamoDB bill: backups or PITR, streams, and global-table replication where DynamoDB itself is creating the line item.
Beside the DynamoDB bill: cache layers, downstream stream consumers, and application retry overhead that may accompany DynamoDB spend but should not be blended into it.

What to model on the bill itself

Read exposure: billable read behavior after item size, consistency, and access pattern are accounted for.
Write exposure: writes plus the write amplification caused by GSIs, transactions, or replication features.
Storage: base table footprint plus projected or duplicated index storage.
Operational extras: PITR, streams, and global tables where they create their own DynamoDB-native line items.
Bill ownership: whether a cost is native to DynamoDB itself or belongs to the systems wrapped around it.

Boundary choices that change ownership

Cache behavior: repeated hot reads may be a cache-design problem even when DynamoDB is absorbing the request volume.
Stream consumers: stream processing cost belongs beside the DynamoDB bill unless the DynamoDB-native stream line item itself is what you are measuring.
Retry storms: application-side failures can inflate DynamoDB usage, but ownership may still sit with the caller or workflow design.

How to gather inputs without mixing jobs

Unit mechanics: use the RCU/WCU explainer to turn request shape into billable exposure instead of rebuilding that logic here.
Adjacency list: keep cache, consumer, and application-side costs beside the DynamoDB bill rather than folding them into one total.
Optimization handoff: only move to the optimization page once you know which bill bucket actually dominates.

When this is not the right page

Go to RCU/WCU explained if you still need to understand how request volume becomes billable read and write exposure.
Go to DynamoDB cost optimization if you already know the bill owner and need production changes such as scan cleanup, index control, or retry reduction.

DynamoDB cost calculator RCU/WCU explained

Validation checklist

Validate that reads, writes, storage, and extras belong to the DynamoDB bill rather than to adjacent cache, consumer, or application systems.
Validate that GSI and replication amplification are treated as first-class bill multipliers, not buried inside one generic request number.
Validate that PITR, streams, and global tables are modeled explicitly whenever they materially change the bill.