.png)
Cloud teams increasingly expect infrastructure to scale automatically without requiring manual capacity planning. DynamoDB on-demand mode charges for the read and write request units consumed by an operation. The number of API calls alone is not enough to calculate cost because item size, consistency, transactions, access pattern and the number of items evaluated can change the units consumed.
From a FinOps perspective, this pricing model shifts the conversation from capacity management to consumption management. Rather than estimating peak demand and allocating resources ahead of time, organizations need to understand how requests, storage, and optional features contribute to their overall DynamoDB costs.
However, on-demand pricing is only one component of the total DynamoDB pricing model. In addition to request charges, costs may also include data storage and optional capabilities depending on how DynamoDB is configured and used.
This article explains how DynamoDB on-demand pricing works, the billing components that influence costs, and the considerations FinOps practitioners should evaluate when assessing workloads that use DynamoDB.
Disclaimer:
All pricing concepts discussed are based solely on the official Amazon DynamoDB Overview and Amazon DynamoDB Pricing pages, together with the Amazon DynamoDB Developer Guide.
Understanding DynamoDB Pricing Fundamentals
At a high level, DynamoDB pricing includes:
- request processing,
- data storage,
- optional data protection capabilities,
- replication features,
- data movement operations, and
- data transfer.
Standard AWS data-transfer pricing may apply to cross-Region application traffic or internet egress. Global Table replication itself does not incur a separate cross-Region data-transfer charge.
Now, depending on your workload, these components may contribute differently to your overall DynamoDB bill. For request processing, DynamoDB offers two capacity modes:
- on-demand, where you pay for the read and write requests your application performs, and
- provisioned, where you specify the amount of read and write capacity your application requires.
Understanding these pricing dimensions provides the foundation for evaluating on-demand capacity from a FinOps perspective.
Rather than viewing request charges in isolation, practitioners should assess how request activity, storage requirements, and optional features collectively influence the total cost of running DynamoDB workloads.
What Is DynamoDB On-Demand Capacity?
Instead, DynamoDB automatically accommodates your workload, and you are billed based on the Read Request Units (RRUs) and Write Request Units (WRUs) consumed by your application’s operations.
According to AWS, on-demand capacity mode is well suited for:
- applications with unknown or unpredictable traffic patterns,
- workloads that can experience sudden increases in request volume, and
- scenarios where managing capacity is not preferred.
This allows teams to focus on application development without planning or provisioning throughput in advance.
For FinOps practitioners, this pricing model shifts attention from estimating capacity requirements to understanding workload consumption patterns.
While DynamoDB automatically manages scaling in on-demand mode, organizations should still evaluate how application traffic translates into billable read and write requests as part of their overall cloud cost analysis.
Both DynamoDB on-demand and provisioned capacity are eligible for AWS Database Savings Plans. They can provide up to 18% savings on eligible on-demand throughput and up to 12% savings on eligible provisioned throughput in exchange for a one- or three-year hourly spend commitment.
Organizations using provisioned capacity may also evaluate Reserved Capacity, which offers larger discounts but applies only to provisioned throughput for Standard table-class workloads within a single AWS Region.
When both Reserved Capacity and Database Savings Plans are present, Reserved Capacity is applied first, while Savings Plans can cover any remaining eligible usage. They do not stack on the same workload.
Initial Throughput and Scaling
Limits
- New on-demand tables can immediately sustain up to 4,000 write request units and 12,000 read request units per second.
- On-demand capacity mode instantly accommodates traffic up to twice the table’s previous peak. For example, a table that has sustained 50,000 reads per second can immediately handle up to 100,000 reads per second without throttling.
- If traffic exceeds twice the previous peak within a 30-minute window, requests can be throttled. AWS recommends pre-warming tables ahead of known traffic events or gradually increasing traffic over at least 30 minutes.
- By default, each DynamoDB on-demand table and each individual Global Secondary Index (GSI) can sustain up to 40,000 read request units and 40,000 write request units per second in an AWS Region.
Organizations expecting sustained throughput beyond these defaults can request quota increases through AWS Service Quotas.
- Teams can also configure a maximum read/write throughput setting per on-demand table and per GSI to cap consumption and bound cost exposure; requests beyond that ceiling are throttled rather than billed.
Hot partitions can still cause throttling
If a disproportionate amount of traffic targets a single partition key, that partition can become a hot partition, causing throttling even when overall table throughput remains well below the table-level quota.
According to AWS guidance, an individual partition is designed to support approximately:
- 3,000 read request units per second, or
- 1,000 write request units per second
How DynamoDB On-Demand
Pricing Works
Request processing is measured using Read Request Units (RRUs) and Write Request Units (WRUs).
The total request-processing cost depends on the number of request units consumed and the applicable price per million request units for your selected AWS Region and table class.
The number of request units consumed depends on four primary factors:
- The type of operation (read or write)
- The consistency model used for read operations
- Whether the request is transactional
- The size of the item being read or written
Understanding Read Request Units (RRUs)
If an item exceeds 4 KB, DynamoDB calculates RRUs in 4 KB increments, rounding up to the next 4 KB increment.
RRU Calculation Examples
| Operation | Item size | Calculation | Total RRUs |
|---|---|---|---|
| Strongly consistent read | 3 KB | Up to 4 KB | 1 RRU |
| Strongly consistent read | 8 KB | 2 × 4 KB increments | 2 RRUs |
| Strongly consistent read | 10 KB | Rounded up to 3 × 4 KB increments | 3 RRUs |
| Eventually consistent read | 10 KB | 3 × 0.5 RRU | 1.5 RRUs |
| Transactional read | 10 KB | 3 × 2 RRUs | 6 RRUs |
Understanding Write Request Units (WRUs)
RRU Calculation Examples
| Operation | Item size | Calculation | Total WRUs |
|---|---|---|---|
| Standard write | 1 KB | Up to 1 KB | 1 WRU |
| Standard write | 3 KB | 3 × 1 KB increments | 3 WRUs |
| Standard write | 5 KB | 5 × 1 KB increments | 5 WRUs |
| Transactional write | 3 KB | 3 × 2 WRUs | 6 WRUs |
| Transactional write | 5 KB | 5 × 2 WRUs | 10 WRUs |
Calculating Monthly On-Demand Costs
The practical test:
The pricing values and calculations in the following example are based on the Amazon DynamoDB Pricing page for the US East (N. Virginia) Region and the Standard table class as of August 2026. AWS pricing varies by Region, table class, and may change over time. Always refer to the official Amazon DynamoDB Pricing page for the most up-to-date pricing before making cost estimates or architectural decisions.
- Already stores 1 TB of historical data.
- Grows to 1.4 TB by the end of the month, averaging 1.2 TB throughout the month.
- Processes 42.5 million write requests and 42.5 million strongly consistent read requests during the month.
- Performs one 1 KB write and one strongly consistent 1 KB read for each user interaction.
| Cost component | Calculation | Monthly cost |
|---|---|---|
| Write requests | 42.5 million WRUs × $0.625 per million WRUs | $26.56 |
| Read requests | 42.5 million RRUs × $0.125 per million RRUs | $5.31 |
| Data storage | 1,200 GB-month average storage − 25 GB Free Tier = 1,175 billable GB-months × $0.25 per GB | $293.75 |
| Total monthly cost | $325.62 |
In this example, the first 25 GB of storage is covered under the AWS Free Tier for the DynamoDB Standard table class, leaving 1.175 TB of billable storage. Although the workload processes 85 million total requests, storage accounts for approximately 90% of the monthly bill ($293.75 of $325.62).
Request-Billing Edge Cases Worth Knowing
Although RRUs and WRUs are calculated primarily from item size and operation type, several DynamoDB behaviors can affect request-unit consumption in ways that are easy to overlook:
- Query and Scan operations are billed based on the amount of data evaluated, not the amount of data returned.
- Filter expressions and projection expressions generally do not reduce read request unit consumption because DynamoDB reads the data before filtering or projecting attributes.
- Reading a nonexistent item still consumes read request units.
- BatchGetItem and BatchWriteItem calculate request units independently for each item rather than treating the batch as one request.
- UpdateItem write capacity is calculated using the larger of the item’s size before or after the update.
- Failed conditional writes and cancelled transactions can still consume request units because DynamoDB evaluates the request before determining whether it succeeds.
- Global Secondary Indexes support only eventually consistent reads.
Understanding these behaviors helps explain why workloads with similar request counts can produce very different DynamoDB bills.
Learn more about DynamoDB read and write operations.
What Counts Toward Billable Storage
- The raw byte size of every attribute name and attribute value in an item. Attribute names count toward item size, so verbose naming conventions measurably increase storage cost at scale.
- Every DynamoDB item includes 100 bytes of storage overhead in addition to its attribute names and values.
As a result, storage growth depends not only on application data but also on indexing and replication configuration.
- Storage for any Global Secondary Indexes, which is calculated independently from the base table.
- Replicated storage in every Region for tables that use Global Tables.
Tracking item sizes over time, not just at design time, is therefore relevant to both cost and the 400 KB ceiling.
The DynamoDB Free Tier that covers the storage above applies per Region, per payer account, and currently includes:
- 25 GB of Standard-class data storage,
- 25 provisioned Read Capacity Units and 25 provisioned Write Capacity Units, which apply to provisioned capacity, not to on-demand request charges,
- 25 replicated WCUs for global tables deployed across two Regions, and
- 2.5 million DynamoDB Streams read requests each month
Key Takeaway for FinOps Teams
Request-processing costs are driven by request volume, item size, consistency model, and transactional operations, while storage contributes independently to the total monthly bill.
The AWS pricing example demonstrates an important FinOps principle: request-processing charges are only one component of DynamoDB costs.
Even with tens of millions of requests, storage can become the dominant cost driver depending on the workload’s data footprint.
In this example, storage represents approximately 90% of the total bill, which is well above AWS’s approximate guideline of 50% storage cost for evaluating the Standard-Infrequent Access (Standard-IA) table class.
Using AWS’s own pricing example, the monthly cost would decrease from $325.62 using the Standard table class to $159.74 using Standard-IA. That’s a reduction of approximately 50.9%.
Whether Standard-IA is appropriate still depends on the workload’s request volume because request-processing prices are higher than the Standard table class.
FinOps teams should therefore evaluate request consumption, storage growth, and table configuration together when analyzing DynamoDB spend.
Beyond Request Processing: Other Costs to Consider
While request processing forms the foundation of DynamoDB’s on-demand pricing model, it is not the only contributor to your monthly bill. Depending on how you configure and use your tables, AWS may charge separately for storage and optional DynamoDB features.
Some of the additional cost components include:
- Data storage: Charges are based on the amount of data stored in your DynamoDB tables. Storage pricing varies by table class and AWS Region, making long-term data growth an important consideration when forecasting costs.
- Continuous backups (Point-in-Time Recovery): DynamoDB charges for continuous backups used with Point-in-Time Recovery (PITR), allowing tables to be restored to any second within the configured recovery window.
- On-demand backups: Charges apply based on the amount of backup data stored. Organizations maintaining multiple backup copies should account for the cumulative storage consumed over time.
- Restore operations: Restoring a table from a backup incurs separate charges based on the amount of data restored.
- Data export to Amazon S3: Exporting table data to Amazon S3 is billed based on the amount of data processed.
- Data import from Amazon S3: Importing data into DynamoDB from Amazon S3 is billed separately.
- DynamoDB Streams: Charges apply for DynamoDB Streams read requests beyond the applicable free tier. Applications that continuously process stream records should include these requests when estimating operational costs.
- Change Data Capture (CDC): DynamoDB charges CDC units for source-table changes sent to Kinesis Data Streams or AWS Glue, in addition to separate charges from the destination service.
- Global Tables: Write requests to a global table are billed as replicated write request units (rWRUs) in each replica Region, and data storage is charged independently in every replica Region.
- Time to Live (TTL): TTL automatically removes expired items without consuming write request units in the source Region. However, when Global Tables are enabled, replicated TTL deletes consume replicated write request units (rWRUs) in each replica Region.
Adding a replica in a new Region incurs a table-restore charge based on the amount of data restored. Writes to any GSIs on a global table are billed at the standard (non-replicated) WRU rate in every Region where the GSI exists, so a heavily indexed global table can see write costs multiply faster than the base table alone.
AWS does not charge a separate cross-region data-transfer fee for global table replication itself. Global tables can also be configured for multi-Region strong consistency (MRSC).
An MRSC table can use a witness Region instead of a third full replica, and because a witness does not store table data, it avoids replica write, storage, and replication-transfer costs.
- Global Secondary Indexes (GSIs): GSIs maintain separate indexed copies of your data and therefore incur their own storage and request-processing charges. Applications with multiple GSIs may experience noticeably higher DynamoDB costs than the base table alone.
- DynamoDB Accelerator (DAX): DAX is priced separately based on the node type and number of nodes deployed, independent of DynamoDB’s on-demand or provisioned charges.
DAX caches eventually consistent reads; strongly consistent and transactional reads always pass through to DynamoDB and are not cached, so DAX does not reduce their cost. AWS notes that DAX performs best when cache-hit rates exceed roughly 90%.
It is not well suited to write-heavy workloads or workloads without repeated reads for the same keys, since a cache miss consumes more cluster resources than a hit.
Evaluating DAX is ultimately a cost comparison: cluster cost against the table-read cost avoided, plus the latency improvement delivered.
Although these services are optional, they can represent a significant portion of the total cost depending on the workload.
For example, a production environment using Global Tables, continuous backups, and data exports will have a different cost profile than a standalone table that only processes application requests.
When Is On-Demand Capacity
the Right Choice?
With provisioned capacity mode, you specify the number of read and write capacity units that your application requires. If your workload exceeds the provisioned capacity, requests may be throttled unless additional capacity is configured or automatic scaling is enabled.
From a workload perspective, AWS recommends on-demand capacity mode for applications with new or unpredictable traffic patterns, workloads that may experience sudden spikes in traffic, and use cases where managing capacity is not preferred.
By comparison, provisioned capacity mode is generally suited to workloads with more predictable traffic patterns where capacity requirements can be estimated in advance.
Choosing between the two modes is ultimately a break-even question. A meaningful comparison weighs the on-demand request-unit cost against the provisioned hourly capacity cost, including any auto-scaling target utilization and minimum provisioned floor.
It also factors in average versus peak utilization, GSI capacity, and whether reserved provisioned capacity or a Database Savings Plan would apply.
Choosing Between On-Demand and
Provisioned Capacity
At current US East (N. Virginia) Standard table class pricing, the raw throughput break-even occurs at approximately 29% average utilization before considering factors such as:
- Auto Scaling minimum capacity
- Free Tier benefits
- Global Secondary Index throughput
- Reserved Capacity
- Database Savings Plans
- Scaling delays
- Workload variability
On the other hand, provisioned capacity generally becomes more economical for stable, consistently utilized workloads.
Learn more: DynamoDB On-Demand vs Provisioned: Cost Comparison at Every Scale
Key Takeaway for FinOps Teams
- On-demand capacity reduces the operational effort of managing throughput and aligns costs directly with request activity.
- Provisioned capacity offers greater control over allocated throughput and may be appropriate for workloads with stable, predictable demand.
FinOps Best Practices for Managing
DynamoDB On-Demand Costs
1. Understand Your Request Patterns
Look for patterns such as:
- Consistent baseline traffic
- Daily or weekly traffic peaks
- Seasonal demand
- Unexpected traffic spikes
Monitoring these patterns using Amazon CloudWatch can also help identify unexpected increases in request activity before they become significant cost drivers.
Reviewing historical usage alongside billing reports provides additional context when investigating changes in DynamoDB spend.
When investigating uneven request distribution, CloudWatch Contributor Insights can help identify hot partition keys, although it is billed separately based on the volume of analyzed events.
Cost-allocation tags can also improve chargeback and reporting, but they must be activated in AWS Billing before they become available in Cost Explorer, and newly activated tags may take up to 24–48 hours before appearing in cost reports.
2. Monitor Item Sizes
Reviewing item sizes periodically can help identify workloads where larger-than-expected items contribute to higher request-processing costs.
Remember that DynamoDB bills request units based on the size of the entire item being read or written. So as items grow over time, each operation may consume more RRUs or WRUs even if the application modifies only a small portion of the item.
3. Evaluate Optional Features Separately
When analyzing your bill, you should evaluate these components individually rather than attributing all spending to standard table reads and writes:
- Independent Feature Costs: Features like Continuous Backups (PITR), On-Demand Backups, Data Import/Export with Amazon S3, and DynamoDB Accelerator (DAX) are billed using entirely separate pricing dimensions (such as flat backup storage per GB, data volumes processed, or hourly cluster node fees).
- Request-Multiplying Features: Features like Global Tables and Global Secondary Indexes (GSIs) are closely tied to your request activity. Global Tables charge for multi-region data replication via Replicated Write Request Units (rWRUs).
- Data Integration Streams: Enabling DynamoDB Streams to capture real-time table modifications is billed based on stream read request volumes. DynamoDB charges CDC units for source-table changes sent to Kinesis Data Streams or AWS Glue. Charges for the destination service, such as Kinesis or Glue, apply separately.
4. Include Storage in Cost Reviews
Cost reviews should therefore consider both:
- Request-processing charges
- Data storage charges
5. Review Capacity Mode Periodically
Periodically reviewing workload behavior helps ensure the selected capacity mode continues to align with application requirements and organizational cost objectives.
6. Set Cost and Throughput Guardrails
- Maximum throughput settings on on-demand tables and GSIs provide a ceiling for successful read and write throughput, helping limit unexpected request-processing charges.
Limiting throughput also introduces an availability trade-off because requests beyond the configured maximum are throttled and may trigger application retries if retry logic is enabled.
- AWS Budgets and Cost Anomaly Detection, to catch spend that deviates from historical baselines before it shows up in the monthly bill.
- CloudWatch throttling metrics and ReturnConsumedCapacity on representative requests, to distinguish genuine traffic growth from inefficient access patterns, such as an oversized Scan, before they become a recurring cost.
- Per-table and per-GSI monitoring, since GSI capacity issues surface as base-table throttling and are easy to misattribute.
- Cost-allocation tags mapped to accounts, environments, or teams, so DynamoDB spend can be attributed to a product or tenant rather than reviewed only in aggregate.
Effective DynamoDB cost management goes beyond tracking monthly spend. Understanding request patterns, item sizes, storage growth, and the use of optional features provides the context needed to interpret costs accurately and support informed optimization decisions.
Frequently asked questions
What is DynamoDB on-demand capacity mode?
On-demand capacity mode is a pricing option in Amazon DynamoDB that automatically accommodates your application's read and write traffic. Instead of provisioning throughput in advance, you pay only for the read and write requests your application performs.
How does DynamoDB calculate on-demand request charges?
Request-processing charges are based on Read Request Units (RRUs) and Write Request Units (WRUs). The number of request units consumed depends on the operation type, item size, read consistency model, and whether the operation is transactional.
What is the difference between on-demand and provisioned capacity?
With on-demand capacity, DynamoDB automatically manages throughput, and you pay for the requests your application performs. With provisioned capacity, you specify the amount of read and write capacity required, and charges are based on the provisioned capacity.
Does item size affect DynamoDB on-demand costs?
Yes. DynamoDB calculates read request units in 4 KB increments and write request units in 1 KB increments. Larger items consume more request units for the same operation than smaller items.
Does DynamoDB on-demand pricing include storage costs?
No. Request-processing charges and data storage charges are billed separately. Depending on your workload, storage and optional features may contribute significantly to your total DynamoDB bill.
