DynamoDB Transactions: 2x the Cost of Standard Operations — When to Use

Every DynamoDB transaction operation consumes exactly twice the write or read capacity of a standard operation. A DynamoDB transactional write on a 1 KB item costs 2 WRU in on-demand mode ($2.50 per million transactional writes) or 2 WCU per second in provisioned mode. 

A DynamoDB transactional read on a 4 KB item costs 2 RRU in on-demand mode ($0.50 per million transactional reads) or 2 RCU per second in provisioned mode (verify at aws.amazon.com/dynamodb/pricing — rates change). This 2x multiplier exists because DynamoDB uses a two-phase commit protocol: one phase to prepare the operation and one to commit it. Both phases consume capacity. 

Failed transactions are still charged for the capacity consumed during the prepare phase. DynamoDB transactions support up to 100 items per request with a maximum aggregate size of 4 MB.

What Is the Exact DynamoDB Transaction Cost Compared to Standard Operations?

Here is the complete DynamoDB standard vs transactional write and read cost comparison for US East (N. Virginia) as of April 2026.

Operation Type	On-Demand Cost	Provisioned Cost	Capacity Per Item	Max Items/Request	ACID Guarantee
Standard Write (PutItem, UpdateItem, DeleteItem)	$1.25/M WRU	1 WCU per 1 KB/sec	1 WRU per 1 KB	1	Per-item only
Transactional Write (TransactWriteItems)	$2.50/M WRU (2x)	2 WCU per 1 KB/sec	2 WRU per 1 KB	100	Multi-item ACID
Batch Write (BatchWriteItem)	$1.25/M WRU	1 WCU per 1 KB/sec	1 WRU per 1 KB	25	None (best effort)
Standard Read (GetItem, strongly consistent)	$0.25/M RRU	1 RCU per 4 KB/sec	1 RRU per 4 KB	1	Per-item only
Transactional Read (TransactGetItems)	$0.50/M RRU (2x)	2 RCU per 4 KB/sec	2 RRU per 4 KB	100	Multi-item ACID
Batch Read (BatchGetItem)	$0.25/M RRU	1 RCU per 4 KB/sec	1 RRU per 4 KB	100	None (best effort)
Eventually Consistent Read (GetItem)	$0.125/M RRU (0.5x)	0.5 RCU per 4 KB/sec	0.5 RRU per 4 KB	1	None

The DynamoDB transaction cost spectrum runs from 0.5x (eventually consistent read) to 2x (transactional write), a 4x range on the same data access. Choosing the wrong operation type for your use case can quadruple your effective per-request cost.

How Does DynamoDB Transaction Cost Scale at Different Volumes?

Here is the dollar impact of using DynamoDB transactions versus standard operations at six scale tiers. All examples assume 1 KB items on on-demand mode in US East (verify at aws.amazon.com/dynamodb/pricing — rates change).

Monthly Operations	Standard Write Cost	Transactional Write Cost	Extra Cost (2x Tax)	Standard Read Cost (SC)	Transactional Read Cost
1 million	$1.25	$2.50	+$1.25	$0.25	$0.50
10 million	$12.50	$25.00	+$12.50	$2.50	$5.00
50 million	$62.50	$125.00	+$62.50	$12.50	$25.00
100 million	$125.00	$250.00	+$125.00	$25.00	$50.00
500 million	$625.00	$1,250.00	+$625.00	$125.00	$250.00
1 billion	$1,250.00	$2,500.00	+$1,250.00	$250.00	$500.00

At 1 billion transactional writes per month, the 2x tax adds $1,250 to your monthly DynamoDB bill. That is $15,000 per year in additional costs solely from using transactions instead of standard writes. If even 30% of those transactions could be replaced with standard operations or batch writes, the annual savings would be $4,500.

Why Do DynamoDB Transactions Cost Exactly 2x?

DynamoDB uses a two-phase commit protocol for every DynamoDB transaction. Both phases consume capacity, which is why the cost doubles.

 

Phase 1: Prepare

DynamoDB validates all items in the transaction, checks condition expressions, and locks the items. This phase consumes 1 WCU per 1 KB write item and 1 RCU per 4 KB read item. If any condition check fails or any item is involved in a conflicting transaction, the entire transaction is cancelled at this point. You are still charged for the capacity consumed during the prepare phase.

 

Phase 2: Commit

If all validations pass, DynamoDB commits all changes atomically. This phase consumes another 1 WCU per 1 KB write item and 1 RCU per 4 KB read item. The commit is all-or-nothing: either every item in the transaction is updated or none are.

Both phases are visible in CloudWatch metrics. The ConsumedWriteCapacityUnits metric reflects the combined capacity of both phases. If you see your consumed WCU spike to 2x your expected write volume, this is the expected behavior when using DynamoDB transactions.

 

Also read: DynamoDB Contributor Insights Pricing

 

Are You Charged for Failed DynamoDB Transactions?

Yes. If a DynamoDB transaction fails due to a condition check failure, a transaction conflict, or insufficient capacity, you are still charged for the read and write capacity consumed during the prepare phase. The prepare phase runs all condition evaluations and item validations before attempting the commit. If the transaction fails at any point during prepare, the capacity consumed up to that point is billed.

This has a compounding effect when transaction conflicts are frequent. Each retry of a failed transaction consumes 2x capacity again. If your application retries a failed DynamoDB transaction 3 times before success, you pay for 4 transaction attempts (3 failed + 1 successful) at 2x capacity each, totaling 8x the capacity of a single standard operation.

 

Using ClientRequestToken for Idempotent Retries

TransactWriteItems accepts an optional ClientRequestToken parameter. If you submit the same transaction with the same token within 10 minutes, DynamoDB returns the result of the original transaction without re-executing it and without charging again. The AWS SDK includes this token automatically, but if you call the API directly, you must include it yourself to avoid paying for duplicate retries.

Best practice: always include a ClientRequestToken for any TransactWriteItems call. If your SDK handles this automatically, verify it in your implementation. Missing the idempotency token means every retry is billed as a new transaction.

How Do Transaction Conflicts Drive Up DynamoDB Transaction Cost?

A DynamoDB transaction conflict occurs when two concurrent transactions attempt to modify the same item. When this happens, one transaction succeeds and the other is cancelled with a TransactionCanceledException. The cancelled transaction is still billed for its prepare-phase capacity, and your application must retry.

CloudWatch provides the TransactionConflict metric, which counts the number of item-level conflicts per table. High conflict rates directly increase your DynamoDB transaction cost because each conflict triggers a retry cycle that consumes additional capacity.

Estimating Conflict Cost

If your table processes 10 million DynamoDB transactional writes per month and 5% fail due to conflicts: 500,000 failed transactions x 2 WRU per transaction = 1,000,000 additional WRU consumed on failed attempts. 

On-demand cost: 1M x $1.25/M = $1.25 extra per month. At 20% conflict rate (common for hot-key workloads): 2,000,000 failed transactions x 2 WRU = 4,000,000 additional WRU. Cost: $5.00 extra per month. At 1 billion writes with 10% conflicts: $125.00 per month in wasted capacity from failed transactions alone.

Reducing conflict rates through better partition key design, smaller transaction scopes (fewer items per transaction), and staggered write timing directly reduces your DynamoDB transaction cost.

How Do GSIs Compound the DynamoDB Transaction Cost?

When a DynamoDB transactional write modifies an item that is projected into a GSI, the GSI update uses standard write capacity (not transactional capacity). However, the GSI update still occurs for every item in the transaction, and it happens in every region for Global Tables.

Worked example: A transaction writing 5 items (1 KB each) to a table with 3 GSIs. Base transaction cost: 5 items x 2 WRU = 10 WRU. GSI propagation: 5 items x 3 GSIs x 1 WRU = 15 WRU (standard rate, not transactional). Total per transaction: 25 WRU. Compare to 5 standard writes: 5 items x 1 WRU = 5 WRU base + 15 WRU GSI = 20 WRU. The transaction adds 5 WRU (25% overhead on top of the already expensive GSI propagation). The combined multiplier: a single transactional write with 3 GSIs consumes 5 WRU per item versus 1 WRU for a standard write without GSIs, a 5x total cost.

For write-heavy transaction workloads, the GSI propagation cost often exceeds the transaction 2x tax itself. Audit your GSI projections (use KEYS_ONLY or INCLUDE instead of ALL) to reduce the compound effect.

When Should You Use DynamoDB Transactions?

DynamoDB transactions exist for a specific purpose: ensuring that multiple item modifications succeed or fail together as a single atomic unit. Use them when the business cost of partial failure exceeds the 2x capacity cost.

Use Transactions For:

Financial operations: Transfer funds between accounts where debiting one and crediting another must both succeed, or both fail. Inventory management: Decrement stock and create an order record atomically to prevent overselling. User registration with uniqueness: Insert a user record and a uniqueness-enforcement record (using a condition check) to prevent duplicate usernames. Multi-entity state changes: Update an order status, log an audit trail record, and update a summary counter in a single atomic operation.

Do Not Use Transactions For:

Single-item updates: A standard PutItem or UpdateItem with a condition expression provides per-item atomicity without the 2x cost. Bulk data loading: BatchWriteItem handles up to 25 items at standard cost with no ACID guarantee. Use it for data ingestion, migrations, and backfills. Read-only operations that tolerate stale data: Use BatchGetItem (standard cost) or eventually consistent reads (0.5x cost) instead of TransactGetItems (2x cost). Idempotent writes: If your write is naturally idempotent (setting a value rather than incrementing), a conditional PutItem is cheaper than a transaction.

What Are the Limits of DynamoDB Transactions?

DynamoDB transactions have specific constraints that affect both cost and architecture (verify at docs.aws.amazon.com/amazondynamodb/latest/developerguide/transaction-apis.html):

Maximum items per transaction: 100. This was increased from 25 in September 2022. Each item can be a Put, Update, Delete, or ConditionCheck operation.

Maximum aggregate size: 4 MB across all items in a single transaction. If your transaction involves large items, you will hit this limit before the 100-item limit.

Same-item restriction: You cannot operate on the same item twice within a single transaction. For example, you cannot both ConditionCheck and Update the same item in one TransactWriteItems call.

Single-region scope: DynamoDB transactions provide ACID guarantees only within a single region. For Global Tables using multi-region eventual consistency (MREC), transactions are local to the originating region. MRSC (multi-region strong consistency) tables support transactions but with additional latency.

No cross-account: All items in a transaction must be in the same AWS account and region. You cannot span transactions across accounts.

Conflict resolution: DynamoDB uses optimistic concurrency control. If two transactions target the same item, one fails with TransactionCanceledException. There is no automatic retry built into the DynamoDB service; your application must implement retry logic.

What Are the Cheaper Alternatives to DynamoDB Transactions?

For many use cases, you can achieve the same business outcome without paying the 2x DynamoDB transaction cost. Here are four patterns that reduce or eliminate the transaction tax.

Alternative 1: Conditional Writes on a Single Item

If your transaction updates a single item, replace TransactWriteItems with a standard UpdateItem using a condition expression. Single-item operations with conditions are atomic by default in DynamoDB. Cost: 1 WRU per 1 KB (standard rate). Savings: 50% versus a transactional write on the same item.

Alternative 2: Combine Related Data into One Item

If your transaction writes to 3 related items (user profile, user settings, user preferences), consider storing all three as attributes in a single item. A single PutItem on the combined item is atomic and costs 1 WRU per 1 KB instead of 3 items x 2 WRU = 6 WRU in a transaction. Savings: up to 83% for a 3-item transaction. Trade-off: larger item size increases the per-operation RCU/WCU if the item crosses a billing threshold (1 KB for writes, 4 KB for reads).

Alternative 3: BatchWriteItem for Non-ACID Bulk Operations

BatchWriteItem handles up to 25 items per request at standard capacity rates with no ACID guarantee. If your use case tolerates partial failure (and you handle retries for unprocessed items), batch writes cost 1 WRU per 1 KB. Savings: 50% per item versus transactional writes. Use for: data migrations, bulk updates, cache warming, log ingestion.

Alternative 4: Application-Level Saga Pattern

For operations spanning more than 100 items or requiring cross-service coordination, implement a saga pattern using DynamoDB Streams and Lambda. Each step writes to DynamoDB with standard operations, and a compensating action rolls back previous steps if a subsequent step fails. Savings: eliminates the 2x tax on all operations. Trade-off: significantly more complex to implement, eventual consistency during the saga execution window, and compensating actions may not fully undo side effects.

 

Also read: AWS Savings Plan: A Complete Guide to Maximizing Savings

 

How Do DynamoDB Transactions Interact with Streams and Global Tables?

Transactions and DynamoDB Streams

DynamoDB Streams captures the results of a transaction after it commits, not during the two-phase commit process. If a transaction writes 5 items, 5 separate stream records are created. Streams does not group these into a single transactional stream record. Your Lambda consumer receives individual item-level changes and cannot distinguish whether they were part of a transaction or individual writes. This means Streams-based consumers cannot enforce transactional consistency downstream.

For event-driven architectures that depend on processing transactional changes as a group, you need to add a correlation attribute (such as a transaction ID) to each item being written. Your downstream consumer can then group stream records by this attribute to reconstruct the transaction boundary. This adds complexity but is the only reliable way to maintain transactional semantics in a Streams-based pipeline.

Transactions and Global Tables

DynamoDB transactions on Global Tables provide ACID guarantees only within the originating region. For MREC (multi-region eventual consistency) tables, the transactional changes replicate to other regions asynchronously after the local commit, with no cross-region ACID guarantee. For MRSC (multi-region strong consistency) tables, transactional operations generate errors and are not supported. This means you cannot use TransactWriteItems or TransactGetItems on MRSC global tables.

If your application requires both transactions and multi-region availability, use MREC Global Tables and accept that the transaction is ACID-local only. Cross-region reads will be eventually consistent regardless of the local transaction guarantee.

Transactions and DAX (DynamoDB Accelerator)

TransactWriteItems and TransactGetItems are both supported with DAX. However, DAX does not cache transactional read results. TransactGetItems bypasses the DAX cache and reads directly from DynamoDB, consuming the full 2x RCU. If your application uses DAX for read caching, transactional reads will not benefit from the cache hit rate that reduces standard read costs. This makes transactional reads effectively more expensive than the 2x multiplier suggests, because you lose the DAX cache cost savings that your standard reads enjoy.

What Does a Real-World DynamoDB Transaction Cost Look Like?

Abstract pricing tables do not capture the full cost picture. Here are three real-world DynamoDB transaction cost scenarios that show how the 2x multiplier interacts with item size, GSIs, and conflict rates.

Scenario 1: E-Commerce Order Placement

An order placement transaction writes 4 items: the order record (2 KB), a payment record (1 KB), an inventory decrement (1 KB), and an audit log entry (1 KB). The table has 2 GSIs projecting all attributes. On-demand mode.

Transaction write cost: Order (2 KB x 2 WRU = 4 WRU) + Payment (1 KB x 2 WRU = 2 WRU) + Inventory (1 KB x 2 WRU = 2 WRU) + Audit (1 KB x 2 WRU = 2 WRU) = 10 WRU total. GSI propagation: 4 items x 2 GSIs x average 1.25 WRU per item = 10 WRU. Grand total per order: 20 WRU. At $1.25/M WRU, 1 million orders per month = 20M WRU = $25.00/month.

Without transactions (standard writes, same items): 4 items x average 1.25 WRU = 5 WRU base + 10 WRU GSI = 15 WRU per order. 1 million orders = 15M WRU = $18.75/month. DynamoDB transaction cost premium: $6.25/month (33% increase) for the ACID guarantee on order placement. For an e-commerce business, that $6.25/month is trivially worth the guarantee that orders, payments, and inventory updates never get out of sync.

Scenario 2: High-Frequency Financial Ledger

A financial ledger processes 50 million double-entry transactions per month. Each transaction writes a debit record (1 KB) and a credit record (1 KB) atomically. No GSIs. On-demand mode.

Transaction write cost: 2 items x 2 WRU = 4 WRU per transaction. 50M transactions x 4 WRU = 200M WRU. Cost: 200M x $1.25/M = $250.00/month. Without transactions: 100M standard writes at 1 WRU each = $125.00/month. DynamoDB transaction cost premium: $125.00/month. This is where the 2x tax becomes a material line item. At this scale, evaluate whether the application can use conditional writes with application-level reconciliation instead of DynamoDB transactions for some operations.

Scenario 3: Gaming Leaderboard with Frequent Conflicts

A real-time gaming leaderboard uses DynamoDB transactions to atomically update a player score and recalculate a rank counter. 20 million transactions per month with a 15% conflict rate due to hot leaderboard keys. On-demand mode.

Successful transactions: 17M x 2 items x 2 WRU = 68M WRU. Failed transactions (still billed): 3M x 2 items x 2 WRU = 12M WRU. Retried transactions (assuming 1 retry each): 3M x 2 items x 2 WRU = 12M WRU. Total WRU: 68M + 12M + 12M = 92M WRU. Cost: 92M x $1.25/M = $115.00/month. Without conflicts (same volume): 80M WRU = $100.00/month. Conflict cost overhead: $15.00/month (15% wasted capacity). At higher conflict rates (30%+), the overhead doubles. Redesigning the partition key to reduce hot spots is the primary cost lever in this scenario.

How Does the ConditionCheck Operation Affect DynamoDB Transaction Cost?

TransactWriteItems supports a ConditionCheck operation that evaluates a condition expression against an item without modifying it. ConditionCheck is commonly used to verify that a referenced item exists before writing to another item in the same transaction.

Cost: Each ConditionCheck consumes 1 RCU (standard read, not 2x transactional) for the item being checked. However, the ConditionCheck still counts toward the 100-item limit per transaction. If your transaction has 5 writes and 10 ConditionChecks, it uses 10 WRU (5 writes x 2 WRU) + 10 RRU (10 checks x 1 RRU) = 10 WRU + 10 RRU.

Common anti-pattern: Using ConditionCheck to validate every item reference in a transaction when the data model could enforce the constraint through key design. Each ConditionCheck adds 1 RCU to your transaction cost and reduces the number of actual write operations you can fit within the 100-item limit.

Best practice: Minimize ConditionCheck operations by designing your data model so that key existence guarantees the constraint you are checking. For example, instead of checking that a User exists before creating an Order, use a composite key (PK: USER#123, SK: ORDER#456) where the order can only be queried under the user’s partition. If the user does not exist, the order is simply unreachable without a separate existence check.

 

Also read: 10 Biggest Cloud Cost Optimization Challenges

 

How Should You Monitor DynamoDB Transaction Cost?

CloudWatch Metrics to Track

ConsumedWriteCapacityUnits and ConsumedReadCapacityUnits: These reflect the 2x consumption from transactions. Compare these to your expected standard operation volume. If consumed capacity is consistently 2x your write/read volume, all your operations are transactional. TransactionConflict: Counts item-level conflicts. High conflict rates mean wasted capacity on failed prepares. Set alarms when conflict rates exceed 5%. SuccessfulRequestLatency for TransactWriteItems and TransactGetItems: Transactions have higher latency than standard operations (typically 10-50 ms vs 1-5 ms). Monitor for latency spikes that may indicate capacity pressure or conflict storms.

Cost Explorer Analysis

Filter Cost Explorer by DynamoDB service and group by usage type. Transactional and standard writes both appear under the same WCU or WRU usage type. To isolate transaction cost, compare your CloudWatch ConsumedWriteCapacityUnits against your application’s transaction log. If consumed, WCU is 2x your write count; transactions are your primary cost driver.

 

Also read: AWS Savings Plan Buying Strategy

 

How Does DynamoDB Transaction Cost Relate to Reserved Capacity Optimization?

If your workload uses provisioned capacity with a significant transaction volume, your effective WCU consumption is 2x what your write volume suggests. This matters for reserved capacity sizing.

Example: A table handling 50 writes per second, all transactional. Effective WCU consumption: 50 x 2 = 100 WCU per second. Without transactions: 50 WCU per second. If you size your reserved capacity at 50 WCU (based on write volume alone), you under-reserve by 50%. The excess 50 WCU runs at the standard provisioned rate, missing the reserved discount.

Size your reserved capacity based on consumed WCU from CloudWatch, not your application write count. CloudWatch already reflects the 2x transaction multiplier.

Usage.ai Flex Reserved Instances for DynamoDB automatically use the CloudWatch consumed capacity data, which includes the transaction multiplier. The platform identifies the stable baseline of consumed capacity (including the 2x factor) and purchases reserved capacity at the correct level. Usage.ai refreshes this analysis every 24 hours versus AWS Cost Explorer’s 72+ hour cycle. If a reservation becomes underutilized, Usage.ai provides cashback and credits on the unused portion. The fee is a percentage of realized savings only.

See how much you can save on DynamoDB with Usage.ai

 

 

Frequently Asked Questions

1. How much does a DynamoDB transaction write cost?

A DynamoDB transactional write costs 2 WRU per 1 KB item in on-demand mode ($2.50 per million transactional writes) or 2 WCU per second per 1 KB in provisioned mode. This is exactly double the standard write cost of 1 WRU or 1 WCU. The 2x cost applies because of the two-phase commit protocol (verify at aws.amazon.com/dynamodb/pricing — rates change).

 

2. What is the difference between standard and transactional write in DynamoDB?

A standard write (PutItem, UpdateItem, DeleteItem) costs 1 WRU/WCU per 1 KB and provides per-item atomicity only. A DynamoDB transactional write (TransactWriteItems) costs 2 WRU/WCU per 1 KB but provides ACID atomicity across up to 100 items. Both update the same data; the difference is the multi-item guarantee and the 2x cost.

 

3. How is DynamoDB cost calculated for transactions?

DynamoDB transaction cost equals 2x the standard capacity for each item in the transaction. A transaction writing 10 items of 1 KB each consumes 20 WRU (10 items x 2 WRU). A transaction reading 5 items of 4 KB each consumes 10 RRU (5 items x 2 RRU). GSI updates from transactional writes use standard WRU rates, not 2x.

 

4. Are failed DynamoDB transactions free?

No. Failed transactions are charged for the capacity consumed during the prepare phase. A TransactionCanceledException due to a condition check failure, conflict, or insufficient capacity still incurs WRU/RCU charges. Use ClientRequestToken to make retries idempotent and avoid double-billing on retried transactions within a 10-minute window.

 

5. What is the 400 KB limit for DynamoDB?

Each individual item in DynamoDB has a maximum size of 400 KB, including all attribute names and values. This limit applies regardless of whether the item is written via a standard operation or a transaction. A single transaction can contain up to 100 items with an aggregate size limit of 4 MB (not 400 KB).

 

6. Can DynamoDB transactions span multiple tables?

Yes. TransactWriteItems and TransactGetItems can operate on items across multiple DynamoDB tables within the same AWS account and region. You cannot span transactions across different accounts or regions. Each item in the transaction specifies its target table name.

 

7. Does DynamoDB support ACID transactions?

Yes, within a single region. DynamoDB transactions provide atomicity (all or nothing), consistency (condition checks enforced), isolation (serializable via optimistic concurrency control), and durability (committed changes are persisted). For Global Tables, ACID applies only in the originating region; cross-region replication is eventually consistent.

 

8. How do DynamoDB transactions compare to BatchWriteItem?

BatchWriteItem handles up to 25 items at standard capacity rates (1 WRU per 1 KB) with no ACID guarantee. TransactWriteItems handles up to 100 items at 2x capacity rates with full ACID. Batch is 50% cheaper per item but provides best-effort delivery: some items may succeed while others fail, requiring your application to handle unprocessed items.