$0.25 per million read request units. That single number from the AWS on-demand pricing page looks simple until you realize it applies only to eventually consistent reads, only in us-east-1, and only after you’ve understood the difference between a read request unit and a read capacity unit. DynamoDB’s pricing has real complexity buried under what AWS markets as straightforward pay-per-use billing.
This article cuts through it. You’ll get exact dollar amounts for both billing modes, a real cost scenario comparing a read-heavy application on each mode, a breakdown of the free tier’s actual limits, and a list of costs that developers routinely miss until the bill arrives.
DynamoDB gives you two ways to pay for throughput: on-demand and provisioned capacity. The choice affects not just how much you pay, but how you architect your application and manage capacity.
On-demand mode charges you per request. No capacity planning, no pre-provisioning. AWS automatically scales to handle traffic spikes.
Pricing in us-east-1 (as of 2025 AWS public pricing page):
One WRU handles one write of up to 1 KB. One RRU handles one eventually consistent read of up to 4 KB. Strongly consistent reads cost 2 RRUs. Transactional reads and writes cost 2x the standard rate.
On-demand is priced roughly 6-7x higher per request unit compared to what you’d pay with provisioned capacity at full utilization. That gap is the core tradeoff you’re managing.
Provisioned capacity charges you for capacity reserved per hour, whether you use it or not.
Pricing in us-east-1:
One WCU sustains one write per second at up to 1 KB. One RCU sustains two eventually consistent reads per second at up to 4 KB. If your workload exceeds provisioned capacity, requests get throttled unless you’ve enabled auto-scaling or you’re briefly within the burst allowance.
Auto-scaling adjusts provisioned capacity based on utilization targets you set (typically 70% target utilization). It helps, but it has response lag of several minutes, which means sudden traffic spikes can still cause throttling before scaling kicks in.
DynamoDB’s free tier is account-level and permanent, not a 12-month trial like most AWS free tier offers.
What it includes:
The 25 WCUs and 25 RCUs are modest. At 25 WCUs, you can sustain 25 writes per second continuously. For a low-traffic application, blog backend, or internal tool, this is genuinely useful at zero cost.
What it does not cover: on-demand capacity requests, DAX, global tables replication, backups beyond the free tier, or data transfer out.
Use the AWS Free Tier Calculator to model whether your expected read/write patterns stay within these limits before committing to an architecture.
Consider a typical read-heavy application with this traffic profile:
Monthly totals:
Peak read rate during the 6-hour window: 80% of 300M reads / (6 hours x 3600 seconds) = 240M / 21,600 = approximately 11,111 reads per second. At 2 KB per item, each read consumes 1 RCU for eventually consistent reads (items under 4 KB). So you need approximately 11,111 RCUs at peak.
Off-peak rate: 60M reads / (18 hours x 3600 seconds) = approximately 926 reads per second, requiring about 926 RCUs.
With auto-scaling targeting 70% utilization, you’d provision roughly 16,000 RCUs to safely handle peak. But you’re paying for those 16,000 RCUs around the clock.
That’s dramatically more expensive than on-demand for this traffic shape. The spike-heavy pattern kills provisioned capacity’s cost advantage.
Now consider a flat traffic profile: the same 300 million reads distributed evenly across the month (roughly 3,472 reads/second at all times).
Wait, that’s more expensive than on-demand’s $98.75. Let me scale this down to show where provisioned capacity wins. The crossover happens at higher, sustained volumes where per-unit costs matter.
At 1 billion reads/month (flat traffic), on-demand costs $250. Provisioned at the required ~11,574 RCUs sustained would cost around $1,095. On-demand still wins here because reads are cheap.
Provisioned capacity wins on write-heavy workloads. At 100 million writes/month on-demand: $125. Provisioned at 40 sustained WCUs: 40 x $0.00065 x 730 = $18.98/month. That’s where provisioned capacity pays off massively: predictable, sustained write throughput.
Global tables replicate data across multiple AWS regions. Each replicated write costs $1.875 per million replicated WRUs (in us-east-1 as of current pricing). If you write 50 million items per month and replicate to two additional regions, you’re paying for 3x the write cost plus storage in each region. The replication cost alone on 50 million writes adds $93.75 per additional region per month.
DAX is DynamoDB’s in-memory cache. It is not free. DAX nodes are billed like EC2 instances, by node type and hour. The smallest node, dax.t3.small, costs $0.054/hour in us-east-1, or approximately $39/month. A production-grade DAX cluster with 3 nodes for high availability runs closer to $120/month at minimum, before considering larger node types for high-throughput workloads.
Teams often add DAX to reduce DynamoDB read costs, but at low read volumes the DAX cost exceeds the savings. The math only works when your read costs are already substantial.
Streams themselves are free to enable. You pay $0.02 per 100,000 read requests against the stream. For event-driven architectures using Lambda to consume streams, this cost is usually minor but can grow with high-write workloads.
A 100 GB table with PITR enabled costs $20/month just for backup protection.
Data transfer out from DynamoDB to the internet follows standard AWS data transfer pricing: the first 100 GB/month is free, then $0.09/GB. Intra-region transfer to other AWS services is generally free. Cross-region transfer for global tables replication is billed separately from the replication write cost.
| Factor | On-Demand | Provisioned |
|---|---|---|
| Write cost (us-east-1) | $1.25/million WRUs | $0.47/WCU-month |
| Read cost (us-east-1) | $0.25/million RRUs | $0.09/RCU-month |
| Throttling risk | None | Yes, if auto-scaling lags |
| Best traffic pattern | Spiky, unpredictable | Steady, predictable |
| Capacity planning needed | No | Yes |
| Auto-scaling available | N/A | Yes |
| Minimum cost | $0 (plus storage) | $0 (free tier covers 25 WCUs/RCUs) |
| Transactional request cost | 2x standard rate | 2x standard rate |
Choose on-demand when:
Choose provisioned when:
You can switch between modes twice per day per table, so starting on-demand and migrating to provisioned after you have real traffic data is a legitimate strategy.
On-demand is the right default for most teams starting out. The premium you pay for unpredictability is worth it until you have enough production data to size provisioned capacity accurately. Guessing low gets you throttling. Guessing high wastes money.
Once you’ve got 30+ days of CloudWatch metrics on your actual read and write patterns, model provisioned capacity against those numbers. Write-heavy workloads with consistent traffic patterns often see 60-70% cost reductions by switching to provisioned. Read-heavy workloads with spiky patterns frequently stay cheaper on on-demand even at scale.
The hidden costs are where budgets actually blow up. DAX, global tables, and PITR each add meaningful monthly costs that don’t show up in the headline on-demand vs provisioned comparison. Model all of them before committing to an architecture. The AWS Free Tier Calculator can help you sanity-check your free tier usage and spot where you’ll start incurring charges.