DynamoDB pricing calculator

Why the write line grows

DynamoDB doesn't bill per request. It bills per request unit, and the unit depends on the item's size, rounded up. A write unit covers 1 KB, so writing a 2.1 KB item costs 3 write units, three times what a 900-byte item costs. Reads are cheaper because a read unit covers 4 KB, and an eventually consistent read, the default, costs half a unit. Transactions double both. That is why the write line is usually the big one even when an app reads ten times more than it writes.

Item size is mostly a design decision. A user record that also carries an activity log, a cart, or a JSON blob of settings gets written in full on every small update. An update expression that changes one attribute doesn't help: DynamoDB charges an update by the size of the whole item, before or after the change, whichever is larger. Moving the fast-changing part into its own small item does.

Indexes count too. Every global secondary index that projects an attribute you changed takes its own write, so a table with three GSIs can pay four times for one update. Projecting only the keys an index needs is the cheapest fix we know.

On-demand is the right default for new or spiky tables. For traffic that is steady around the clock, provisioned capacity with auto scaling usually costs a fraction of it, which is what the comparison line shows. It assumes your writes and reads are spread evenly over the month and auto scaling targets 70% use, so treat it as the floor, not a quote.

We walk through each of these lines with worked numbers in DynamoDB pricing: why writes cost more than you think.

If DynamoDB is a bigger part of your AWS bill than this page says it should be, send us the bill. It is usually item size, an index nobody reads, or a table left on on-demand after its traffic settled.