AWS DynamoDB Cost: A Pricing Guide for Engineers

AWS DynamoDB is one of those services that engineers adopt fast and audit late. It's fully managed, scales automatically, and delivers single-digit millisecond latency without a server to touch. But the billing model is genuinely complex, and the gap between "we're paying for DynamoDB" and "we know exactly what we’re paying for and why" is wider than most teams expect.

The complexity often compounds silently, in the background. A table gets created, a capacity mode gets picked, a few Global Secondary Indexes get added, and Point in Time Recovery (PITR) gets enabled as a precaution. Each decision is reasonable in isolation, but those small choices here and there build up, and the bill that results six months later reflects all of them at once. Without a clear model for how each dimension drives cost, it's hard to know which decision to revisit first.

And the problem isn't just technical. DynamoDB spend is notoriously difficult to attribute. Tables are often shared across services and teams, tags are inconsistently applied, and index costs roll up into base table metrics in ways that obscure the real source of a spike. Visibility is easy to get. Understanding what's actually driving the number is the hard part.

This guide breaks down how DynamoDB costs accumulate, where bills grow faster than workloads justify, and what gives you the most control over spend.

Key Takeaways

• AWS DynamoDB cost is driven by three factors: reads, writes, and storage. Two capacity modes determine how each is billed.
• Choosing between on-demand and provisioned capacity is the single most consequential pricing decision for any DynamoDB table.
• Global Secondary Indexes are a billing multiplier. Every write to the base table triggers a write to every GSI, and over-projected attributes compound that cost over time.
• Optional features like global tables, PITR, and DAX carry their own billing dimensions that accumulate independently of base table costs.
• DynamoDB spend is difficult to attribute without additional tooling. Tables are often shared infrastructure, and manual tags rarely reflect actual ownership at scale.

What Is Amazon DynamoDB?

Amazon DynamoDB is a fully managed, serverless NoSQL database that handles key-value and document data. AWS provisions, patches, and scales the underlying infrastructure automatically. There's no instance to size, no read replica to configure, and no maintenance window to plan around.

For teams who need single-digit millisecond latency at any scale, DynamoDB delivers without requiring deep database administration expertise. It's a natural fit for applications with unpredictable traffic, high-throughput event processing, user session storage, and any workload where access patterns favor lookups by a known key over complex relational queries.

But the billing model doesn't match the operational simplicity. DynamoDB pricing involves three core billing dimensions, two capacity modes, and a set of optional features that each carry their own cost structures. Those elements interact in ways that aren't obvious when a table is first created, and the configuration decisions made then compound over the life of the workload.

What Drives AWS DynamoDB Cost?

DynamoDB cost is determined by three core factors: reads, writes, and storage. The capacity mode you choose determines how all three translate into charges. On-demand bills per request. Provisioned bills for capacity reserved in advance, regardless of whether it's consumed.

But those three factors are just the foundation. The real complexity comes from the optional features layered on top. Global tables, point-in-time recovery, DynamoDB Streams, and DAX each generate charges on their own billing dimensions, independent of base table costs. And because most of these features are enabled per table rather than per account, costs accumulate across your table inventory in ways that are easy to miss until the bill arrives.

Beyond the base table billing, a range of optional features generate additional charges:

DynamoDB Capacity Modes: On-Demand vs. Provisioned

Choosing a capacity mode is the single most consequential DynamoDB pricing decision. Both modes cover reads, writes, and storage but bill those dimensions differently. The right choice depends on your traffic pattern.

On-Demand Capacity Mode

On-demand capacity bills per request with no pre-provisioning required. DynamoDB scales automatically and you're charged only for what you use. It fits two situations: new tables without usage history, and workloads with genuinely unpredictable or spiky traffic.

Read billing uses Read Request Units (RRUs). The rate depends on consistency:

• A strongly consistent read of up to 4 KB consumes 1 RRU
• An eventually consistent read of up to 4 KB consumes 0.5 RRUs
• A transactional read of up to 4 KB consumes 2 RRUs

Write billing uses Write Request Units (WRUs). A standard write of up to 1 KB consumes 1 WRU. Transactional writes cost 2 WRUs, making transactions a meaningful cost multiplier for write-heavy workloads.

In November 2024, AWS reduced on-demand pricing, shifting the breakeven point between on-demand and provisioned and making on-demand competitive for a wider range of workloads. Teams who set capacity modes before that change should revisit them.

US East (Ohio) region. Verify current rates in AWS documentation.

Provisioned Capacity Mode

Provisioned capacity bills for RCUs and WCUs reserved in advance, charged hourly regardless of actual consumption. One RCU covers one strongly consistent read per second (up to 4 KB), or two eventually consistent reads. One WCU covers one write per second (up to 1 KB).

Provisioned mode works best for steady-state workloads with predictable traffic. Per-unit provisioned rates are lower than on-demand rates at sustained throughput.

Auto scaling adjusts allocations within bounds you define, but it has latency. Reserved capacity, available as a 1-year or 3-year commitment, provides the largest discounts and is worth evaluating for any mature table with a stable baseline.

Reflecting the 25% throughput premium on Standard-IA. US East (Ohio) region. Verify current rates in AWS documentation.

On-Demand vs. Provisioned: Which Mode Costs Less?

The answer depends on the workload. And the right answer for one table in your account may not be the right answer for the table next to it.

The risk in provisioned mode is over-provisioning. Teams that set allocations conservatively to avoid throttling often pay for capacity that's consistently underutilized. That idle capacity doesn't generate an alert. It just keeps billing at the hourly rate while CloudWatch shows the gap between provisioned and consumed capacity.

DynamoDB Storage Cost

DynamoDB storage cost is calculated per GB-month and applies to all live data stored within your table and its secondary indexes.

The first 25 GB of storage per month is free, but only for the Standard table class. The free tier does not apply if you choose the Standard-Infrequent Access (Standard-IA) class.

The total storage footprint of a table includes the raw data values plus the structural overhead of your schema:

• Attribute Names: Every attribute name is stored inside every item, meaning verbose naming directly inflates your storage bill.
• Per-Item Overhead: DynamoDB adds a flat 100 bytes of overhead to every item.
• Secondary Indexes: Global (GSI) and Local (LSI) secondary indexes add storage costs based entirely on the specific attributes you choose to project into them.

Note: Table backups (PITR and on-demand snapshots) are billed as separate line items at lower per-GB rates; they are not billed at the live table's storage rate.

Rates based on US East (Ohio) region.

Optional Feature Costs Worth Knowing

While base tables handle your core data, enabling optional features introduces distinct pricing dimensions. Managing these features carefully is the key to preventing cloud bill shock.

1. Backup and Restore: On-demand backups are manual snapshots that remain until deleted; without a strict lifecycle policy, they accumulate costs silently. Continuous backups (PITR) provide a rolling 35-day recovery window. Applying PITR universally without evaluating actual recovery tier requirements is a common source of waste.
2. Global Tables: This feature provides multi-region replication by charging Replicated Write Units on top of base writes. Because every write is pushed to every replica region, each additional region acts as a direct cost multiplier.
3. DynamoDB Streams & CDC: Streams capture a time-ordered change log, offering a generous free tier before metered billing kicks in. For massive data pipelines feeding into external analytics, Change Data Capture (CDC) for Kinesis or Glue charges a flat rate per million change units.
4. DynamoDB Accelerator (DAX): DAX adds an always-on cluster cost. It only saves money if the read request units (RRUs) it eliminates from your base table exceed the fixed hourly cost of the nodes. For low- or intermittent-read workloads, DAX will actively inflate your bill.

DynamoDB Pricing: How to Read Your AWS Bill

DynamoDB charges appear in AWS Cost Explorer under the Amazon DynamoDB service line. To make sense of a bill, you must group the data by usage type to separate core operations: reads (ReadRequestUnits / HeavyUsage:Read), writes (WriteRequestUnits / HeavyUsage:Write), and total storage (TimedStorage-ByteHrs).

It’s important to remember that while a cost spike in daily reads is instantly visible in Cost Explorer, identifying which specific application, team, or microservice caused it is a notoriously difficult problem.

Manual, tag-based cost allocation rarely solves this problem at scale for three reasons:

1. Infrastructure-as-Code Gaps: Tables are frequently spun up via CI/CD pipelines with inconsistent, missing, or typo-ridden tags.
2. The Shared Infrastructure Problem: Cost allocation tags apply strictly at the table level, not the operational level. If three different engineering teams or services query the exact same database table, a resource tag cannot split the bill between them.
3. Bundled Index Costs: Because storage and throughput for Global Secondary Indexes (GSIs) roll up into the base table's metrics, index costs cannot be isolated via native billing tags.

When the bill spikes, tracing the root cause traditionally requires digging into application logs or checking CloudWatch metrics and DynamoDB Contributor Insights to see which specific access patterns or data keys blew up the budget.

How to Reduce AWS DynamoDB Cost

1. Choose the Right Capacity Mode for Each Table

Don't apply the same capacity mode across your entire stack by default. Evaluate each table's traffic pattern independently.

• Use On-Demand for: New tables without usage history, development/staging environments, and production workloads with erratic, unpredictable spikes. (Note: Following recent AWS pricing cuts, on-demand is highly competitive even for moderate traffic).
• Use Provisioned for: Mature tables with stable, baseline throughput. To mitigate the risk of idle capacity, always pair provisioned mode with Target Tracking Auto Scaling (e.g., targeting 70% utilization) to automatically handle gradual shifts in traffic.

2. Right-Size GSIs to Limit Write Amplification

Every time you write to a base table, DynamoDB must replicate that write to all of its Global Secondary Indexes (GSIs). If your GSI is improperly configured, you pay a steep "write amplification" penalty.

• Audit Projections: Review your GSIs. If they are configured with an ALL projection type, change them to INCLUDE (only projecting the specific attributes your queries actually look for) or KEYS_ONLY.
• Leverage Sparse Indexes: If a query only looks for a small subset of records, ensure the GSI sort key is only populated on those specific records. If the attribute doesn't exist on an item, DynamoDB won't write it to the index, saving both storage and throughput.

3. Select the Right Table Class

DynamoDB Standard-Infrequent Access (Standard-IA) drops storage costs by 60% but increases read/write request costs by 25%.

The golden rule is to only move a table to Standard-IA if storage makes up more than 50% of that table's total monthly cost. It is ideal for application logs, audit trails, and data kept strictly for regulatory compliance.

4. Automate Data Lifecycles with TTL

Time-to-Live (TTL) is a free background process. By defining a timestamp attribute, DynamoDB automatically wipes out expired items from your base table and all associated indexes without consuming any of your billable write capacity. Use it aggressively for session data, short-term logs, and transient data cache layers.

5. Leverage Flexible Commitments

If you have stable, predictable tables in Provisioned mode, do not pay standard hourly rates.

Use Database Savings Plans to commit to a consistent hourly spend across your account. This grants up to an 18% discount on on-demand throughput (12% on provisioned throughput) and remains flexible if your database architecture changes over time. For massive, permanent, single-region tables, traditional Reserved Capacity offers the deepest discounts (up to 77%).

AWS DynamoDB Cost FAQ

Is DynamoDB free to use?

DynamoDB includes a free tier of 25 GB of storage per month and 25 RCUs and 25 WCUs of provisioned capacity. The free tier applies to Standard table class tables using provisioned capacity, and is granted per Region, per payer account, so it's available in every Region DynamoDB runs in rather than a fixed set of Regions. For most production workloads, usage exceeds the free tier, and standard charges apply above those limits.

What is the most expensive part of DynamoDB?

It depends on the workload. Write amplification from GSIs dominates on write-heavy tables with multiple indexes. RRU or RCU charges dominate on high-read workloads. Storage becomes the primary driver on tables with large item sizes or high cardinality. Identifying the source requires the breakdown in Cost Explorer, not just the total service line.

When should I use provisioned capacity vs. on-demand?

Use provisioned when you have several months of stable usage data and can define throughput bounds with confidence. Use on-demand when the workload is new or variable. After the November 2024 pricing reduction, on-demand is now competitive for a broader range of workloads.

How does DynamoDB storage cost compare to other AWS database services?

DynamoDB storage costs are $0.25 per GB-month on the Standard class, which is higher than Amazon S3 but lower than RDS provisioned storage. Teams who store infrequently accessed data in DynamoDB when S3 or a cheaper tier would serve the access pattern are paying for capabilities they don't use.

Can I switch capacity modes after a table is created?

Yes. A table can be switched to on-demand once per 24 hours, with the same constraint on switching back. The switch doesn't require a rebuild or downtime and takes effect immediately.

Connecting DynamoDB Cost to Engineering Action

Understanding what drives DynamoDB cost is straightforward once you've worked through the pricing model. The harder problem is getting the right engineer to make the right change.

Most teams can identify the cost drivers. Cost Explorer shows which tables consume capacity. CloudWatch shows whether provisioned capacity is underutilized. But that information lives in AWS tooling, and the engineers who can act on it work in Jira and GitHub.

DynamoDB spend is also hard to attribute accurately. Tables are shared infrastructure, tags are incomplete, and ownership isn't always clear from the table name alone. A recommendation to right-size a table or audit its GSIs is only actionable if it reaches the team who owns it, with enough context to act.

CxM surfaces DynamoDB optimization opportunities across the usage and configuration levers, assigns ownership automatically using CxM Attribution, and routes recommendations into Slack, Jira, and GitHub. A finding about over-provisioned capacity on a specific table goes to the engineer who owns it, with the context needed to act confidently.

The result is DynamoDB cost reduction that ships as tracked, verified work rather than a line item on a dashboard no one acts on.

Ready to see what DynamoDB optimization opportunities exist in your environment? Book a demo to learn how CxM identifies and closes cloud cost gaps across your AWS infrastructure.