A high-throughput SaaS table can look inexpensive in a load test and costly in production. DynamoDB pricing depends on more than request volume, because item size, index design, read consistency, and traffic peaks all change the bill.
Two services with identical monthly API calls can therefore have sharply different database costs. A useful forecast models throughput pricing alongside item size, index writes, storage, recovery, and regional replication. Validate the estimate with the AWS pricing calculator.
Key Takeaways
- In us-east-1, on-demand DynamoDB charges are $1.25 per million write request units (WRUs) and $0.25 per million read request units (RRUs) for Standard tables. Rates vary by Region.
- Provisioned capacity works best when a stable baseline justifies paying for capacity by the hour. Auto scaling can adjust capacity around that baseline, but it doesn’t eliminate minimum-capacity charges or scaling lag. Consider reserved capacity only after demand stabilizes and the commitment is modeled against official AWS rates. On-demand capacity suits uncertain traffic and rapid growth.
- A write consumes write capacity units (WCU) in 1 KB increments. Reads consume read capacity units (RCU) in 4 KB blocks, while strong consistency and transactions raise consumption.
- Global secondary indexes, Global Tables, backups, Streams, and cross-Region transfer often explain the gap between a simple request estimate and the AWS invoice.
- For SaaS unit economics, track DynamoDB consumption by tenant, feature, endpoint, and Region instead of treating the database as an unallocated platform cost.
How DynamoDB Pricing Works for SaaS Traffic
All dollar figures below use the DynamoDB Standard table class in US East (N. Virginia), us-east-1, unless stated otherwise. Rates can vary by Region, table class, and capacity modes, so confirm the applicable meter on the official DynamoDB pricing page before approving a budget.
On-demand versus provisioned capacity
Capacity modes are a workload decision based on baseline utilization, variability, peak-to-average demand, and predictability.
On-demand capacity bills every read and write request unit. It has no capacity setting, so it fits a new product, unpredictable launches, tenant-specific spikes, and workloads that can fall close to zero overnight.
Provisioned capacity bills the capacity you configure each hour. In us-east-1, a write capacity unit costs $0.00065 per hour, and a read capacity unit costs $0.00013 per hour. Provisioned tables can use auto scaling, but the configured minimum remains billable. Auto scaling changes configured capacity over time, but it doesn’t remove minimum capacity, scaling lag, or sudden-spike risk.
AWS also offers one-year and three-year reserved capacity terms for provisioned workloads. Evaluate these options only after a stable baseline remains through product releases, seasonal traffic, and customer growth. Validate the Region-specific provisioned and on-demand comparison with the AWS pricing calculator.
Read and write request units, including rounding
DynamoDB measures traffic in read request units and write request units. Write capacity units (WCU) are consumed according to item size. One WCU supports one standard write per second for an item up to 1 KB. DynamoDB rounds a 1.1 KB non-transactional write to two WCUs under the same request-unit rules in every Region.
Read capacity units (RCU) are calculated in 4 KB blocks. One RCU supports one read per second for an item up to 4 KB. Strongly consistent reads consume one full RCU per 4 KB block. Eventually consistent reads consume half as many units, while transactional reads and writes consume twice the units for the same item size.
That rounding makes attribute names, nested JSON, and optional fields financial decisions. A payload that moves from 1 KB to 1.01 KB can double write consumption, even when the extra data seems minor.
The Throughput Multipliers That Change the Forecast
Base-table throughput is only the start. High-volume SaaS systems often add indexes and replicas as product requirements expand.
Global secondary indexes add write consumption
A GSI is one of DynamoDB’s secondary indexes, and it creates its own indexed item. When a base-table write changes data that appears in the index, DynamoDB consumes write capacity for both the table item and the GSI item.
Project only attributes needed by the access pattern. KEYS_ONLY, INCLUDE, and ALL attribute projections affect index size, storage, and write consumption. A broad ALL projection can push index writes across 1 KB boundaries. Sparse indexes can reduce this cost when only a subset of records needs a query path.
A GSI can double a write forecast before storage grows by a single gigabyte.
Auto scaling can adjust local table and index capacity, but it doesn’t remove GSI write consumption or change the underlying request volume.
Item size includes more than business data
DynamoDB counts attribute names and values in item size. Long JSON property names, duplicated tenant metadata, verbose status fields, and large unstructured blobs all increase request units.
Keep large documents outside hot items when the application rarely needs them during ordinary reads. For example, an object reference in Amazon S3 can cost fewer database units than repeatedly reading an embedded document.
Also measure index-item size separately. A compact base record doesn’t protect the budget if an index projects a large set of attributes.
Global Tables multiply writes across Regions
Multi-region replication multiplies write and storage considerations across replica Regions, rather than merely improving availability. Global Tables replicate writes to every selected replica Region. AWS charges replicated write units in each replica Region, and cross-Region data transfer can add another charge.
Use this planning formula:
Global Table write cost = source WRUs + replicated WRUs in each replica Region + cross-Region transfer + index writes in each Region
Evaluate source writes, replicated write request units, local GSI writes, storage, backup copies, and cross-Region data transfer separately for each Region and its applicable regional rate. Model read locality, write distribution, item size, index projections, and replication topology before setting a recovery objective.
A two-Region design isn’t a universal multiplier. Forecast source traffic, replication traffic, GSI changes, backups, and local read patterns in every Region.
Storage, Backups, Streams, and the Free Tier
Throughput usually dominates a busy operational table, but long retention periods can shift more spend into storage and recovery services.
Standard and Standard-IA table classes
In us-east-1, Standard table storage costs $0.25 per GB-month. Amazon also offers the Standard-IA table class for data stored long term but accessed infrequently.
Standard-IA changes both storage and request economics, so compare total request, storage, and access costs. Don’t select it only because its storage price appears lower. A table with frequent reads, writes, or index updates may still cost less in Standard.
Calculate data storage from the real average item size. Billed totals include the base table, GSIs, and each replica. A 100 GB base table with two replicated Regions and a large GSI can hold far more billed storage than the original 100 GB estimate suggests.
Recovery, Streams, and the AWS Free Tier
For us-east-1 Standard tables, point-in-time recovery costs $0.20 per GB-month. On-demand backups cost $0.10 per GB-month, and restoring a backup costs $0.15 per GB restored. AWS details how backup storage and restores appear in its DynamoDB backup billing guidance.
DynamoDB Streams cost $0.02 per 100,000 read requests in us-east-1. Multiple consumers, retention requirements, and downstream processing patterns can increase DynamoDB Streams read-request costs. Those workloads may also create separate downstream service charges.
DAX is a separate caching service for read-heavy SaaS workloads, with its own instance-hour cost. Cache hit rate and eviction behavior affect its value, and DAX doesn’t eliminate base-table writes, storage, backup, or replication charges.
For qualifying Standard tables, the AWS Free Tier includes 25 GB of storage and 2.5 million Streams read requests monthly. Qualifying provisioned usage includes 25 WCUs and 25 RCUs. These allowances rarely change a high-throughput production forecast. AWS’s DynamoDB service overview explains the core billing dimensions.
Model Monthly Costs for a High-Throughput SaaS Application
A credible model begins with measured request distributions, not average item size from a schema diagram. Separate the forecast by table, index, operation type, consistency setting, and Region.
Include item-size percentiles, the read/write mix, GSI count and projection, storage growth, backup and PITR choices, Streams consumers, DAX where applicable, peak-to-average demand, and replica count. For multi-region replication, calculate local writes, replicated writes, storage, backups, and data transfer separately for every replica.
A view-count cost example
Assume a SaaS application in us-east-1 records 500 million view events per 30-day month. Each event writes one non-transactional item of 1 KB or less, uses on-demand capacity, has no GSI, no Global Tables, and excludes storage, backups, Streams, and transfer.
Under these item-size assumptions, the base table consumes 500 million write capacity units, with one unit for each event. The calculation below is an illustrative us-east-1 estimate, not a universal 2026 price:
500 million WRUs x $1.25 per million WRUs = $625 per month
Validate this worksheet against the official AWS pricing page and pricing calculator before publication. The $1.25 per million WRUs figure can vary by Region, pricing model, or AWS pricing updates.
Now assume one GSI receives every event and its indexed item is also 1 KB or less. The index adds another 500 million write capacity units, so write charges become $1,250 per month under the same us-east-1 assumptions. The GSI’s projection and indexed item size should be measured separately, since both can change the write-unit total.
If the application also performs 200 million eventually consistent reads of items up to 4 KB, it consumes 100 million read capacity units. At $0.25 per million RRUs, that adds $25 per month. The working estimate is then $1,275 per month, before other billable services.
This illustrative us-east-1 estimate excludes storage, backups, PITR, Streams, DAX, Global Tables, and data transfer. It also excludes any additional indexes or consumers. Confirm the $0.25 per million RRUs figure against the official AWS pricing page before treating the result as a 2026 forecast.
AWS provides an on-demand table estimation pattern that can help turn production metrics into a repeatable worksheet.
Model peaks before choosing provisioned capacity
For a 30-day, 720-hour month in us-east-1, continuously provisioning 2,000 WCUs costs:
2,000 WCUs x 720 hours x $0.00065 = $936
Provisioning 500 RCUs for strongly consistent reads of items up to 4 KB costs:
500 RCUs x 720 hours x $0.00013 = $46.80
These are illustrative us-east-1 estimates, not universal 2026 prices. Validate the WCU-hour and RCU-hour figures against the official AWS pricing page and pricing calculator. Compare the fixed baseline with an auto scaling policy that responds to measured demand.
Those figures assume every unit stays configured for every hour. If traffic averages 200 writes per second but peaks at 2,000 only during brief campaigns, a fixed 2,000-WCU setting buys headroom but leaves much of the purchased capacity unused.
Model minimum capacity, target utilization, scale-out lag, scale-in behavior, and peak headroom. Test each input against per-minute and per-hour demand data, including launch-day and failure-recovery scenarios. Include peak-to-average ratios and any replica-specific capacity requirements.
Use per-minute and per-hour demand data. Then test normal, launch-day, and failure-recovery scenarios. Auto scaling can reduce waste, but minimum capacity, scaling lag, and sudden spikes still need deliberate headroom. Recheck the assumptions as traffic, item sizes, indexes, and storage growth change.
DynamoDB Cost Optimization for FinOps Teams
Cost control works when engineering metrics and billing data describe the same workload.
Measure billable behavior, not only API volume
Track ConsumedReadCapacityUnits, ConsumedWriteCapacityUnits, throttles, item-size percentiles, and GSI activity in Amazon CloudWatch. Review those metrics alongside auto scaling policies and their recent changes.
Compare them with Cost and Usage Report line items to spot changes caused by a deployment or a new customer integration. Correlate changes to minimum capacity, target utilization, or auto scaling behavior with the matching charges.
A request count alone cannot reveal whether an endpoint switched to strongly consistent reads or began returning larger items. AWS’s DynamoDB billing usage guidance helps map usage types to the charges that appear on an invoice.
Use a three-way comparison of measured consumption, Cost and Usage Report charges, and the AWS pricing calculator to validate regional rates and capacity-mode assumptions. Attribute provisioned/on-demand usage, GSI activity, replicated writes, storage, Streams, backups, and DAX costs where possible.
For a full SaaS margin view, include API Gateway, compute, logging, transfer, and DynamoDB. A cost per API call analysis provides a practical framework for assigning those shared costs.
Make ownership visible at the tenant level
Shared DynamoDB tables need application-level allocation. Record tenant ID, feature name, endpoint, Region, response size, and capacity consumed in application telemetry. Cost allocation tags can organize tables, but they can’t isolate one tenant’s activity inside a shared partition design.
Review large tenants that create disproportionate write, index, or replicated-write load. Rate limits, retention rules, event aggregation, and a paid usage tier can protect margins without weakening the product for typical customers.
FAQ
What is the practical difference between on-demand and provisioned capacity?
On-demand charges request units as they occur and absorbs uneven traffic. Provisioned capacity charges configured RCUs and WCUs by the hour, which can lower costs when demand has a stable, well-understood baseline.
How much do DynamoDB Global Tables cost?
There is no universal total because AWS prices replicated writes in each replica Region and charges cross-Region transfer separately. Build the estimate from local writes, replicated writes, index writes, storage, backup copies, and network transfer for every replica.
When should a SaaS team use eventually consistent reads?
Use them when the product can tolerate a short delay before the newest write appears. For items up to 4 KB, eventually consistent reads consume half the capacity units of strongly consistent reads. Use strongly consistent reads only where the application requires read-after-write behavior or a strict business invariant.
Final Cost Perspective
The durable lesson in DynamoDB pricing is that request count is a starting point, not a forecast. Item boundaries, GSIs, consistency, peak capacity, and replicas determine the amount each request consumes.
A model that includes those multipliers will support better architecture decisions and more credible SaaS unit economics.
