.png)
Amazon DynamoDB is AWS’s flagship NoSQL database. It has been fully serverless since its 2012 launch — no instances to provision, no capacity to manage at the infrastructure level, no database software to install or maintain. When engineers search for ‘DynamoDB Serverless,’ they are typically asking about on-demand capacity mode: the billing configuration where you pay per read and write request without any pre-commitment or capacity planning.
The per-request pricing model is elegant in theory. In practice, five hidden cost multipliers mean most teams pay significantly more than their initial estimates. A team that models its DynamoDB spend based on base WRU/RRU rates and item count alone frequently finds its actual bill is two to five times higher. Understanding why is worth understanding before you commit to an architecture for DynamoDB at scale.
This guide explains what DynamoDB Serverless means, how on-demand billing works at every level, including the hidden multipliers, the complete pricing comparison between on-demand and provisioned, and the cost optimization path through the Standard-IA table class, reserved capacity, and Database Savings Plans.
See exactly what you’re overpaying in under 60 seconds. Try the Calculator for free →
What DynamoDB Serverless Actually Means
DynamoDB is always serverless. AWS operates the database hardware, software, replication, failover, and scaling transparently. You create tables, read and write items, and pay for what you use. There are no instances to choose, no nodes to configure, and no operating system to manage.
The ‘serverless’ question in DynamoDB is purely about billing mode. On-demand capacity mode is the true serverless billing experience: you pay per request with automatic capacity scaling and zero cost when tables are idle. Provisioned capacity mode requires pre-committing to a throughput level (read/write capacity units per second) and paying for that capacity whether or not you use it.
On November 1, 2024, AWS reduced on-demand throughput prices by 50% and Global Tables replicated write prices by up to 67%. AWS stated: ‘most provisioned capacity workloads on DynamoDB will achieve a lower price with on-demand mode. This pricing change is transformative as it makes on-demand the default and recommended mode for most DynamoDB workloads.
DynamoDB On-Demand Pricing: The Base Rates
| Billing Component | Rate (Standard Table, US East) | Notes |
| Write Request Unit (WRU) | $1.25 per million | 1 WRU = 1 KB write. Items > 1 KB round up. Transactional writes: 2 WRUs per KB. LWTs: standard WRU rate. |
| Read Request Unit (RRU) — strongly consistent | $0.25 per million | 1 RRU = 4 KB strongly consistent read. Items > 4 KB round up to next 4 KB boundary. |
| Read Request Unit (RRU) — eventually consistent | $0.125 per million | 0.5 RRU per 4 KB. Half the cost of strongly consistent. Default read mode for GetItem with ConsistentRead: false. |
| Transactional writes (TransactWriteItems) | $2.50 per million | 2 WRUs per 1 KB (2x standard). Applies to all items in the transaction. |
| Transactional reads (TransactGetItems) | $0.50 per million | 2 RRUs per 4 KB (2x standard). Applied to all items in the transaction. |
| Storage — Standard table class | $0.25/GB-month | First 25 GB free permanently. Includes table data and LSI storage. |
| Storage — Standard-IA table class | $0.10/GB-month | 60% cheaper storage. WRU/RRU ~25% higher. Best when storage dominates cost. |
| PITR backup | $0.20/GB-month | Optional per-table. Continuous per-second backups. 35-day restore window. Must enable per table. |
| On-demand backup storage | $0.10/GB-month | Manual point-in-time snapshots. Charged from creation until deletion. |
| Table restore from backup | $0.15/GB restored | Per GB of data in restored table including GSI data. |
| Global Tables replicated writes | $1.25 per million (same as single-region since Nov 2024) | Pre-Nov 2024: replicated writes cost 67% more. Now same price. Source: AWS official Nov 2024 announcement. |
| DynamoDB Streams | 2.5M free reads/month, then standard RRU rates | Lambda triggers read Streams for free. Free tier generous for most Lambda architectures. |
| Free tier (permanent) | 25 GB storage + 25 WCU + 25 RCU provisioned | Permanent free tier. Not limited to 12 months. Standard table class only. |
All rates: US East (N. Virginia), Standard table class, June 2026. Verify at aws.amazon.com/dynamodb/pricing — rates change.
Sources: WRU $1.25/million and RRU $0.25/million verified from wring.co (March 2026), cloudburn.io (April 2026), LeanOps (April 2026), dynobase.dev — all citing AWS official. PITR $0.20/GB-month from cloudburn.io (April 2026). Storage rates from cloudfix.com (May 2026) and pump.co. Transactional rates from AWS official DynamoDB pricing. Global Tables change from AWS official announcement November 14, 2024. Verify all at aws.amazon.com/dynamodb/pricing — rates change.
The Five Hidden Costs That Multiply Your DynamoDB Bill
The base WRU and RRU rates are only the starting point. These five cost multipliers are the reason actual DynamoDB bills are consistently higher than initial estimates.
Hidden Cost 1: GSI Write Amplification
This is the most common source of unexpected DynamoDB spend. Global Secondary Indexes (GSIs) allow queries on non-primary-key attributes. Every write to a base table also writes to each GSI that contains the written item’s projected attributes. If your table has 3 GSIs, a single 1 KB write to the base table costs 4 WRUs total (1 for the base table + 1 for each of the 3 GSIs).
Dollar impact: a table doing 10 million writes per month with 3 GSIs actually consumes 40 million WRUs. At $1.25/million: $50/month instead of $12.50/month. At 500 million writes per month: $625/month in write costs for the GSI amplification alone — on top of the $625/month for the base table writes.
The correct way to estimate DynamoDB write costs: identify the number of GSIs on each table. Multiply the base WRU count by (1 + number of GSIs). This is your true WRU consumption for write-heavy workloads. Teams that project costs from the base table write alone systematically underestimate DynamoDB spend by a factor proportional to their GSI count. Source: LeanOps (April 2026) citing AWS official DynamoDB pricing documentation.
Hidden Cost 2: Item Size Rounding (Always Rounds Up)
DynamoDB writes are billed in 1 KB increments, rounded up. Reads are billed in 4 KB increments, rounded up. A 1.1 KB item costs 2 WRUs to write, not 1.1 WRUs. A 4.1 KB item costs 2 RRUs to read strongly consistently, not 1.025 RRUs.
At scale, this rounding has a measurable financial impact. A table where 40% of items are between 1.0 KB and 2.0 KB pays nearly double the WRU cost for those items compared to items under 1 KB. A table where items average 4.2 KB pays nearly double the RRU cost for strongly consistent reads compared to items at 4.0 KB.
Optimization: keep items compact. Use attribute names that are as short as practical. Store only attributes that are actually queried or projected into GSIs. Remove null or empty attributes. An item that fits in 1 KB instead of 1.2 KB cuts its write cost in half.
Hidden Cost 3: Transactional Operations at 2x Premium
TransactWriteItems and TransactGetItems provide ACID transaction guarantees across multiple items in a single operation. The cost: all items in a transactional operation are billed at 2x the standard WRU/RRU rate. A 1 KB write in a TransactWriteItems call costs 2 WRUs instead of 1. A 4 KB read in a TransactGetItems call costs 2 RRUs instead of 1. Source: AWS official DynamoDB pricing documentation.
Teams that use DynamoDB transactions for every write — applying ACID semantics where not strictly required — pay 2x throughput costs on their entire write path. Transactions are appropriate for multi-item atomic operations (update balance AND create transaction record atomically). They are not necessary for single-item writes with a condition expression, which DynamoDB handles atomically at the standard WRU rate using conditional writes.
Hidden Cost 4: Filter Expressions Read All, Bill All
DynamoDB filter expressions are applied server-side after data is read from a partition. DynamoDB reads all matching items from the partition, evaluates the filter, and returns only items that pass. But billing is based on data read, not data returned. Source: cloudburn.io (April 2026) citing AWS official.
A query that reads 100 items from a partition but returns only 10 after filtering consumes capacity for all 100 items. If each item is 4 KB, the query costs 100 RRUs even though it returns 10 items’ worth of data. For workloads with low filter selectivity — where a large fraction of scanned items are discarded — this can make individual queries significantly more expensive than expected.
The fix: design your partition key and sort key to match your access patterns so that queries naturally return only the items you want without post-read filtering. Sparse indexes (GSIs with only a subset of items projected) are often more efficient than table scans with filters for selective access patterns.
Hidden Cost 5: Global Tables Multiplies Storage Per Region
DynamoDB Global Tables replicates your data across multiple AWS Regions for low-latency reads and writes globally. Each region maintains a full copy of the table. Storage is billed per region. A 100 GB table in a Global Table spanning 3 regions is billed as 300 GB of storage per month — 3x the single-region cost. At $0.25/GB-month: $25/month single-region versus $75/month for 3-region Global Table. Source: wring.co (March 2026) and cloudburn.io (April 2026).
Post-November 2024, Global Tables replicated write costs dropped to match single-region write costs. Storage per region remains the full data copy cost. For global applications where low-latency regional writes are required, Global Tables is often worth the storage multiplication. For applications that only need global reads (not writes), consider a single-region table with DynamoDB DAX caching at regional locations, which can be cheaper for read-heavy global applications.
Also read: What Is Amazon ElastiCache? The Complete Guide
On-Demand vs Provisioned: The 2026 Break-Even Analysis
The November 2024 50% on-demand price reduction changed when provisioned is worth the management overhead. Here is the current break-even.
The Math
Provisioned capacity costs $0.00065/WCU-hour and $0.00013/RCU-hour. Source: wring.co (March 2026) and AWS official pricing. A table provisioned at 1,000 WCUs/second for a full month costs: 1,000 x $0.00065 x 730 = $474.50/month in write capacity. The same throughput on on-demand at 1,000 writes/second sustained: 1,000 writes/sec x 2,628,000 seconds/month = 2.628 billion WRUs x $1.25/million = $3,285/month. Provisioned is 6.9x cheaper at sustained high throughput. Source: wring.co (March 2026), consistent with cloudburn.io (April 2026).
At 500 writes/second sustained: on-demand $1,688/month versus provisioned $234/month. That is a $17,448/year difference per table at this throughput. Source: wring.co (March 2026).
The break-even point: on-demand is cheaper when your average throughput over the month is low relative to the peak. The crossover is approximately when sustained average throughput exceeds 15-20 WRU/second or RRU/second. Below that, on-demand costs less than provisioned because the total request count does not accumulate enough to exceed the provisioned per-hour cost. Above that, provisioned capacity becomes progressively cheaper as throughput grows.
Decision rule: use on-demand for any table where the throughput pattern is variable, unpredictable, or where average utilization is below 20% of peak. Use provisioned with auto-scaling for any table with consistent sustained throughput above 100 WRU/second. Use provisioned with reserved capacity for production tables that have run at high consistent throughput for 6+ months. The transition path: start on-demand, monitor CloudWatch for sustained high utilization, and switch to provisioned once the pattern is confirmed.
The Standard vs Standard-IA Table Class Decision
DynamoDB offers two table classes with different storage and throughput pricing trade-offs.
Standard Table Class (Default)
Storage: $0.25/GB-month (first 25 GB free). Throughput: $1.25/million WRUs, $0.25/million RRUs on on-demand. The Standard class is optimized for frequently accessed data where throughput is the dominant cost. Source: AWS official DynamoDB pricing, cloudfix.com (May 2026).
Standard-IA Table Class
Storage: $0.10/GB-month — 60% cheaper than Standard. Throughput: approximately $1.56/million WRUs and $0.31/million RRUs — roughly 25% higher than Standard. Standard-IA is designed for data that is stored for long periods but accessed infrequently. Source: cloudfix.com (May 2026), wring.co (March 2026).
Break-even between Standard and Standard-IA: Standard-IA saves $0.15/GB-month on storage but costs 25% more per request. The table class switch is worth it when storage costs dominate over throughput costs. For a table with 100 GB of data accessed 1 million times per month: Standard storage = $25/month, Standard-IA storage = $10/month (saving $15). Standard-IA throughput premium: 1 million WRUs x ($1.56 – $1.25)/million = $0.31 additional per month. Net saving: $14.69/month. The more data stored relative to access frequency, the more Standard-IA saves.
Important constraints for Standard-IA: you cannot purchase reserved capacity for Standard-IA tables. Reserved capacity is only available for Standard table class provisioned throughput. If you plan to use reserved capacity as a cost optimization lever, the table must stay on the Standard class. Source: AWS official DynamoDB pricing page.
Also read: AWS Database Savings Plans: A Quick Guide
Reserved Capacity: The Deepest Discount for Stable Workloads
Reserved capacity is the deepest discount available for DynamoDB provisioned throughput — up to 77% savings versus on-demand. Source: wring.co (March 2026). Reserved capacity works by committing to a minimum level of provisioned read and write capacity units for a 1-year or 3-year term in exchange for an upfront fee and reduced hourly rates.
Reserved capacity is available only for: Standard table class, single-region provisioned throughput (RCUs and WCUs). It is NOT available for: Standard-IA tables, replicated WCUs in Global Tables, or on-demand mode tables. Source: AWS official DynamoDB pricing page.
For a table doing 500 consistent writes/second: provisioned without reserved = 500 WCUs x $0.00065/hr x 730 = $237/month. With reserved capacity at the reduced rate, the effective hourly rate drops significantly. The exact reserved capacity rates vary by term length (1-year or 3-year) and upfront payment amount — verify current rates at the AWS DynamoDB pricing page under Reserved Capacity.
Database Savings Plans offer an alternative discount mechanism with more flexibility: up to 35% savings with no upfront payment required, applicable across DynamoDB and other database services. Reserved capacity delivers deeper discounts (up to 77%) but requires upfront payment and instance-type lock-in. For tables with very stable, consistent provisioned throughput where the maximum discount justifies the commitment rigidity, reserved capacity wins. For teams managing multiple database services with variable workloads, Database Savings Plans provide more practical flexibility. Source: AWS official DynamoDB pricing page and Usage.ai live DSP blog.
DynamoDB Accelerator (DAX): When Caching Reduces DynamoDB Costs
DAX (DynamoDB Accelerator) is a fully managed, in-memory cache for DynamoDB. It provides microsecond read latency versus DynamoDB’s single-digit millisecond latency. From a cost perspective, DAX matters because it intercepts read requests before they reach DynamoDB, reducing the RRU consumption charged by DynamoDB.
DAX pricing: per node-hour with no free tier and no reserved pricing. DAX nodes start at approximately $0.269/hour for a dax.r4.large (13.5 GB, 4.5 GB/sec read throughput).
When DAX reduces DynamoDB costs: for read-heavy workloads where a significant fraction of reads hit the same items repeatedly (hot keys), DAX caches those items in memory and serves them without a DynamoDB read. If your workload reads the same 1,000 product catalog items millions of times per day, DAX reduces DynamoDB RRU consumption to only cache misses and writes. The math: if a DAX node at $0.269/hr costs $197/month and eliminates $500/month of DynamoDB RRU charges, DAX delivers $303/month net savings.
When DAX does not reduce costs: for workloads with low key reuse (most reads hit different items), DAX cache hit rates will be low and the DAX node cost will not be offset by DynamoDB savings. For write-heavy workloads where writes dominate the DynamoDB bill, DAX does not help because it only caches reads.
DynamoDB Global Tables: Cost Impact of Multi-Region
Global Tables provides active-active multi-region replication for DynamoDB. Every write in any region propagates to all other regions automatically.
Write cost post November 2024: replicated writes are now priced at $1.25/million — the same as single-region writes. Previously, replicated writes were priced at 67% more than single-region writes. This change significantly reduced the cost of global applications.
Storage cost: each region in a Global Table maintains a full copy of the data. A 100 GB table in 3 regions is billed as 300 GB of storage at $0.25/GB-month = $75/month. Single-region storage would be $25/month. The storage multiplication by region count is the primary ongoing cost difference for Global Tables.
PITR per region: if PITR is enabled, it is enabled per region and billed per region. A 100 GB table with PITR in 3 regions: 300 GB x $0.20/GB-month = $60/month in PITR charges. Single-region PITR would be $20/month.
Global Table restore in secondary region: restoration to a secondary region incurs the same per-GB restore fee as single-region restores, charged separately for the target region.
How to Reduce Your DynamoDB Bill: Prioritized Actions
1. Count Your GSIs and Evaluate Their Necessity
Each GSI on a write-heavy table adds a full write cost multiplication. Before adding a GSI, verify it is actively used by production queries. Unused GSIs are pure cost waste: write amplification with no query benefit. Remove GSIs that have not been used in the past 30 days. Use CloudWatch metrics (ConsumedWriteCapacityUnits on GSIs) to identify which indexes receive traffic.
2. Use Eventually Consistent Reads Where Possible
Eventually consistent reads cost half of strongly consistent reads ($0.125/million versus $0.25/million RRUs). DynamoDB’s default for GetItem, Query, and Scan operations is eventually consistent. Only enable strongly consistent reads (ConsistentRead: true) on read paths where your application cannot tolerate reading data that is up to 1 second stale. For most application reads — product catalogs, user preferences, session data — eventual consistency is acceptable and cuts read costs in half.
3. Compact Items Below the Billing Boundaries
Keep item sizes below 1 KB for write-heavy workloads and below 4 KB for read-heavy workloads to stay within the billing unit boundary. Use short attribute names (a, b, c instead of account_number, balance, currency). Remove attributes that are not needed for production queries. Store large binary objects in S3 and keep only the S3 key reference in DynamoDB.
4. Switch Stable Tables to Provisioned with Auto-Scaling
For tables with consistent throughput above approximately 100 WRU/second, provisioned capacity with auto-scaling is significantly cheaper than on-demand. The overhead is configuring min/max WCU/RCU bounds and monitoring for throttling. AWS Cost Explorer shows your DynamoDB tables sorted by cost — start with the highest-spend tables and model the provisioned cost at their observed throughput. Switch tables one at a time after testing auto-scaling behavior.
5. Move Infrequently Accessed Tables to Standard-IA
Tables storing historical data, audit logs, archival records, or any data accessed less than once per week are candidates for Standard-IA. The 60% storage cost reduction ($0.10 versus $0.25/GB-month) is material for large tables with low access rates. Table class changes are immediate, take effect within minutes, and require no data migration or application changes. Source: cloudfix.com (May 2026).
6. Use Database Savings Plans for Provisioned Tables
Database Savings Plans provide up to 35% savings on eligible DynamoDB usage with no upfront payment and full flexibility to change table configuration within the term. For provisioned tables that are stable but where the upfront payment for reserved capacity is not practical, DSP delivers meaningful savings with lower commitment risk. Note: you cannot combine DSP and reserved capacity on the same table usage — reserved capacity is applied first. Source: AWS official DynamoDB pricing page.
See exactly what you’re overpaying in under 60 seconds. Try the Calculator for free →
How Usage.ai Handles DynamoDB Cost Optimization
Usage.ai analyzes DynamoDB table-level spend and identifies the three highest-leverage actions: capacity mode mismatches (tables on on-demand where sustained throughput makes provisioned cheaper), table class opportunities (Standard tables where Standard-IA would reduce storage costs based on access patterns), and Database Savings Plans commitment sizing for stable provisioned table spend.
For capacity mode analysis, Usage.ai monitors ConsumedWriteCapacityUnits and ConsumedReadCapacityUnits per table from CloudWatch to calculate actual sustained throughput and compare against on-demand versus provisioned cost at current rates. The 24-hour refresh means the analysis reflects current utilization rather than a 72-hour-old snapshot from native AWS tools.
For GSI cost analysis, Usage.ai identifies write-heavy tables with high GSI counts and surfaces tables where GSI consumption is a significant share of total write costs, alongside recommendations for GSI consolidation or removal based on CloudWatch GSI-level metrics.
Database Savings Plans for DynamoDB are evaluated alongside other eligible services (Neptune, Keyspaces, ElastiCache, RDS). Usage.ai recommends a single DSP commitment covering multiple database services rather than separate RI purchases per service when the combined workload allows it. Fee: percentage of realized savings only.
See how Usage.ai optimizes DynamoDB capacity mode, table class, and Database Savings Plans
Frequently Asked Questions
1. What is DynamoDB Serverless?
DynamoDB is always serverless — no servers to manage, no clusters to size, no database software to operate. ‘DynamoDB Serverless’ typically refers to on-demand capacity mode, where you pay $1.25 per million write request units (WRUs) and $0.25 per million read request units (RRUs) with no pre-commitment. On-demand mode dropped 50% on November 1, 2024 and is now AWS’s recommended default mode for most DynamoDB workloads. You pay zero when tables are idle. Source: AWS official announcement (November 14, 2024).
2. How much does DynamoDB on-demand cost?
On-demand billing (US East, Standard table class, June 2026): writes at $1.25 per million WRUs, strongly consistent reads at $0.25 per million RRUs, eventually consistent reads at $0.125 per million RRUs (half of strongly consistent). Transactional writes: $2.50/million (2x standard). Transactional reads: $0.50/million (2x standard). Storage: $0.25/GB-month (first 25 GB free). PITR: $0.20/GB-month when enabled. Verify at aws.amazon.com/dynamodb/pricing — rates change. Source: wring.co (March 2026), cloudburn.io (April 2026), LeanOps (April 2026).
3. Why is my DynamoDB bill higher than expected?
Five common causes: (1) GSI write amplification — each GSI adds a full write cost per write to the base table; a table with 3 GSIs costs 4x the base WRU rate per write. (2) Item size rounding — writes round up to the next 1 KB, reads to the next 4 KB. (3) Transactional operations at 2x standard WRU/RRU rate. (4) Filter expressions bill for all scanned data, not just returned data. (5) Global Tables storage multiplied per region. Audit your tables for GSI count, item sizes, transaction usage, and filter expression selectivity. Source: cloudburn.io (April 2026), LeanOps (April 2026).
4. When is DynamoDB provisioned cheaper than on-demand?
Provisioned capacity ($0.00065/WCU-hour, $0.00013/RCU-hour) becomes cheaper than on-demand above approximately 20 WRU/second sustained throughput. At 500 writes/second sustained: on-demand $1,688/month versus provisioned $234/month — provisioned is 7x cheaper. At 1,000 writes/second: on-demand $3,375/month versus provisioned $780/month. For tables with consistent predictable throughput, switch to provisioned with auto-scaling. Source: wring.co (March 2026). Verify with current rates at aws.amazon.com/dynamodb/pricing.
5. What is DynamoDB Standard-IA?
DynamoDB Standard-Infrequent Access (Standard-IA) is a table class with 60% lower storage costs ($0.10/GB-month versus $0.25/GB-month) and approximately 25% higher read/write rates. Switch to Standard-IA for tables where storage is the dominant cost and access is infrequent. Standard-IA cannot use reserved capacity. Table class changes take effect immediately with no data migration. Source: cloudfix.com (May 2026), wring.co (March 2026).
6. What changed in DynamoDB pricing in November 2024?
On November 1, 2024, AWS reduced DynamoDB on-demand throughput prices by 50% and Global Tables replicated write prices by up to 67%. The replicated write price now equals the single-region write price ($1.25/million WRU on-demand). AWS stated this makes on-demand ‘the default and recommended mode for most DynamoDB workloads.’ Source: AWS official announcement (November 14, 2024): ‘Amazon DynamoDB reduces prices for on-demand throughput and global tables.’
7. Do Database Savings Plans cover DynamoDB?
Yes. Database Savings Plans cover DynamoDB and provide up to 35% savings on a 1-year commitment. The commitment is a dollar-per-hour spend level applicable across DynamoDB and other eligible database services. You cannot combine DSP and reserved capacity on the same table usage — reserved capacity is applied first, with remaining usage eligible for DSP. For provisioned tables where reserved capacity is practical, reserved capacity provides deeper discounts (up to 77%). Source: AWS official DynamoDB pricing page and Usage.ai live DSP blog.
