DynamoDB bills you for three things: the writes you send, the reads you serve, and the data you store. Everything else, including indexes, replication, streams, and backups, is a variation on those three. Get the model right and DynamoDB stays cheap at scale. Get it wrong and a single deploy can turn a $150 monthly bill into thousands of dollars a day, which is a real case one team documented after an $8,963 charge over 72 hours.

This guide breaks down every cost dimension with current numbers, gives you a clean rule for choosing a capacity mode, and shows where bills go wrong. The structure mirrors how teams reason about other AWS services, the same way our AWS EC2 pricing guide maps compute spend.

What you pay for in DynamoDB

DynamoDB charges on four buckets:

• Throughput: reads and writes, priced either per request (on-demand) or per provisioned capacity unit per hour (provisioned).

• Storage: per GB-month, in a Standard tier or a cheaper infrequent-access tier.

• Optional features: global tables, DynamoDB Streams, DAX, point-in-time recovery, and backups.

• Data transfer: standard AWS egress rates, with the first 100 GB out per month at no charge.

Two details drive most surprises. Reads are metered in 4 KB units and writes in 1 KB units, and DynamoDB rounds up. An item just over 1 KB costs two write units, not one. And you pay for data read, not data returned, so a filter expression trims your response but never your bill.

On-demand vs provisioned: the core decision

On-demand is pay-per-request with no capacity planning. You are billed per read request unit (RRU) and write request unit (WRU). Current US East rates are $0.625 per million WRU and $0.125 per million RRU, after AWS cut on-demand throughput prices by 50%. It suits spiky, new, or unpredictable workloads.

Provisioned bills per capacity unit per hour whether you use it or not: $0.00065 per WCU-hour and $0.00013 per RCU-hour (rates). One write capacity unit handles one 1 KB write per second; one read capacity unit handles one strongly consistent 4 KB read per second, or two eventually consistent reads. It suits steady, forecastable traffic and unlocks reserved capacity discounts.

The break-even rule most guides get wrong

A provisioned unit run at full use costs about $1.81 per 100 million writes; the on-demand equivalent costs $6.25. That makes on-demand roughly 3.5 times the fully-used provisioned price, so provisioned wins once a unit stays busy more than ~29% of the time. Many older pages still quote a ~14% break-even, which was the math before the price cut. Run the current numbers and the threshold is higher, which is one reason AWS now suggests on-demand as the default starting point.

A worked monthly example

Take a table sustaining 100 writes per second and 200 eventually consistent reads per second of small items, plus 100 GB of storage over a 30-day month:

For this steady workload, provisioned is roughly 60% cheaper. Halve the utilization and provisioned still wins. Push traffic into unpredictable spikes and on-demand pulls ahead because you stop paying for idle capacity.

Storage tiers

Stored data costs $0.25 per GB-month in the Standard table class. The Standard-Infrequent Access class drops storage to $0.10 per GB-month but raises read and write rates, so it pays off only when data is read rarely. This is the same tier-tradeoff logic covered in our guide to navigating AWS storage costs. Match the table class to access frequency rather than defaulting to Standard for everything.

Optional feature costs

These line items are where bills quietly inflate:

A common mistake is treating indexes as free query helpers. Each GSI multiplies your write cost and carries independent storage, so a table with three indexes pays roughly four times the write throughput on every put.

The free tier

DynamoDB includes an always-free allowance of 25 WCU, 25 RCU, and 25 GB of storage for Standard-class tables, which never expires. That covers most prototypes and small internal tools outright, and it trims a slice off every production bill.

Why DynamoDB bills surprise teams

The capacity model is predictable. The application behavior on top of it is not. Three patterns cause most blowups:

• Runaway on-demand traffic: On-demand has no ceiling. A retry storm or a hot loop keeps billing with no cap, which is how the $9K surprise happened.

• Query fan-out: Because NoSQL has no joins, one API request can trigger dozens of reads. One reported case fired 47 queries behind a single call.

• Large items and scans: Oversized items multiply per-operation cost, and a full-table scan reads and bills every item even when you return a handful.

The connective tissue is visibility. Teams that monitor performance but not cost only learn the price after the invoice. Tying DynamoDB spend back to a team or feature is the same unit-economics discipline behind broader FinOps practice.

How to reduce DynamoDB cost

Practitioner tactics that move the bill, in rough order of impact:

1. Keep items small: Writes round up per 1 KB and reads per 4 KB, so shaving an item under a threshold can halve its per-operation cost.

2. Be deliberate with GSIs: Create an index only for an access pattern that is genuinely latency-critical. Drop the speculative ones.

3. Prefer queries over scans: Scans read the whole table. A query on a key reads only what it needs, and filters do not lower the read charge.

4. Use TTL for expiry: Time-to-live deletes stale items automatically at no charge, holding down storage.

5. Move media to S3: Store large blobs in S3 and keep only the pointer in DynamoDB.

6. Buy reserved capacity for steady workloads. Committing provisioned capacity for one or three years discounts throughput steeply, the same commitment logic as Savings Plans versus Reserved Instances on compute.

For a wider toolkit across services, our roundup of AWS cost optimization tools covers the platforms that automate this work.

Monitor DynamoDB spend with Amnic

Pricing knowledge prevents the obvious mistakes. Continuous visibility prevents the expensive ones. Amnic attributes DynamoDB cost down to the table, surfaces the capacity-mode and reserved-capacity moves worth making, and flags anomalies before they reach the invoice. You can see live spend in the cost analyzer and act on automated recommendations instead of reading the damage after the fact.

Conclusion

DynamoDB pricing is not complicated once you separate it into throughput, storage, and features, then layer the capacity-mode decision on top. Use the current numbers, not the pre-cut ones. Apply the ~29% utilization rule to pick a mode, watch item size and indexes, and keep cost in view continuously. Do that and DynamoDB stays one of the most cost-efficient databases at scale rather than a source of month-end shocks.

FAQs

How is DynamoDB priced? 

DynamoDB charges for three core things: write throughput, read throughput, and stored data. On-demand bills per request, provisioned bills per capacity unit per hour, and storage is billed per GB-month. Optional features like indexes, streams, and backups add separate line items.

Is DynamoDB expensive? 

It depends on the workload shape. DynamoDB is cheap for key-value access at scale but costly for heavy scans, many global secondary indexes, large items, or frequent transactions, which each multiply per-operation cost. Right-sizing the capacity mode keeps it efficient.

Is on-demand or provisioned cheaper for DynamoDB? 

Provisioned is cheaper for steady traffic, roughly when a capacity unit stays utilized above 29% of the time. On-demand wins for spiky or unpredictable workloads because you pay nothing for idle capacity and avoid over-provisioning.

Does DynamoDB have a free tier? 

Yes. DynamoDB includes an always-free allowance of 25 write capacity units, 25 read capacity units, and 25 GB of storage for Standard-class tables. The allowance does not expire and applies on top of paid usage.

Why is my DynamoDB bill so high? 

Common causes are uncapped on-demand traffic from retries or hot loops, query fan-out from NoSQL access patterns, full-table scans, oversized items, and unmanaged secondary indexes. Each multiplies read or write charges quietly.

How can I reduce DynamoDB costs? 

Keep items small, limit global secondary indexes to critical access patterns, use queries instead of scans, set TTL to expire stale data, store large media in S3, and buy reserved capacity for predictable provisioned workloads.