Practical guide
DynamoDB pricing: convert item size into request units
calculate DynamoDB request units from item size. Includes a worked example, calculator scope, and practical questions.
Updated · Sources checked
Price consumed units, not business operations
DynamoDB on-demand cost depends on consumed read and write request units. Item size, read consistency, and transactional behavior determine how many units an operation consumes. A million application operations is therefore not automatically a million billed units.
The calculator accepts millions of consumed units for Standard on-demand usage in US East. It does not infer item size or transaction semantics from an API call count.
Worked example: writes across a size boundary
Consider one million ordinary writes of items that are each 1.5 KB. Under the write billing increment, each requires two write request units, producing two million units in total. If an application redesign reduces the item size below or equal to 1 KB without adding writes, those operations require one million write units.
The arithmetic difference is one million write units. Multiply that by the applicable per-unit price, or enter two and one in the calculator’s millions-of-write-units input to compare supported scenarios.
This example assumes ordinary nontransactional writes and excludes index updates. It is not a recommendation to split items blindly: splitting one logical record into several writes can erase the apparent saving and change consistency or application behavior.
Keep read semantics separate
Read units use their own size increments and consistency rules. Strongly consistent, eventually consistent, and transactional reads should not be mixed without converting them into consumed units first. For a workload containing different item sizes, aggregate cohorts or use actual consumed-capacity measurements rather than rounding one monthly byte average.
Global secondary indexes, global tables, storage, backups, streams, transfer, and other features are outside the focused calculator subtotal. Include them separately when estimating the cost of a schema or indexing change.
Measure serialized item size including attribute names and values. The business payload alone can understate the database item’s size, especially near a billing boundary where a small increase can require another unit.
Frequently asked questions
Can I enter the number of API calls directly? Only if you have already established the consumed units per call for that workload.
Do reads and writes use the same units? No. Convert each independently with its applicable size and operation rules, then supply their totals.
Calculate your scenario
Use the dynamodb cost calculator. Keep the displayed region, pricing date, billing units, and exclusions alongside your result. The arithmetic examples above illustrate usage or explicitly hypothetical rates; they are not AWS quotes.
Source
Billing structure checked against official AWS documentation on September 6, 2026.