DynamoDB cost optimization: capacity mode, GSIs, TTL, and table class

Quick answer

DynamoDB cost is throughput + storage + GSIs + extras (global tables, DAX, backups). The biggest levers: match capacity mode to traffic (on-demand for spiky, provisioned + autoscaling + reserved for steady), prune unused GSIs (each is a second copy with its own throughput and storage), set TTL to delete expired items, and use the Standard-IA table class for cold, storage-heavy tables.

DynamoDB scales seamlessly, which is exactly why its cost can creep: nothing breaks as you add indexes, retain data, and over-provision capacity — the bill just grows. The good news is that the cost drivers are few and each has a clear lever.

Start with capacity mode

The first decision is on-demand (pay per request) versus provisioned (pay per hour for set capacity). On-demand suits spiky or unpredictable traffic; provisioned with autoscaling suits steady load, and reserved capacity on top discounts steady provisioned throughput further. The full comparison is in DynamoDB on-demand vs provisioned; getting this right is usually the largest single saving.

Prune the indexes

Each global secondary index is effectively a second table — its own throughput and storage, replicated from the base. A table with four GSIs can cost several times the base table. Two fixes:

Drop GSIs you don't query. They cost whether or not you read them.
Project only needed attributes into each GSI rather than ALL, so the index copies less data.

Shrink storage with TTL and table class

TTL auto-deletes expired items for free — essential for sessions, events, and caches that would otherwise accumulate storage and inflate GSIs forever.
Standard-IA table class cuts storage ~60% for tables where storage dominates and access is infrequent (logs, archives), at the cost of higher request rates — so not for hot tables.

The rest of the bill

Avoid full-table scans — query by key; scans burn read capacity proportional to table size.
DAX only when read-heavy and latency-sensitive — it's an always-on cluster cost, justified by offloading reads.
Global tables multiply write cost per region — enable only for genuine multi-region needs.

FAQ

What drives Amazon DynamoDB costs?

Throughput (read/write capacity, whether on-demand per-request or provisioned per-hour), storage per GB-month, global secondary indexes (each GSI consumes its own throughput and storage), and optional features like global tables, DAX, and backups. The biggest swings come from capacity mode choice and unnecessary GSIs.

How do I reduce DynamoDB costs?

Match capacity mode to traffic (on-demand for spiky, provisioned + autoscaling for steady), buy reserved capacity for steady provisioned throughput, prune unused GSIs, set TTL to auto-delete expired items, use the Standard-IA table class for infrequently-accessed data, and design queries to avoid full-table scans.

Do global secondary indexes cost extra?

Yes — each GSI is essentially a second copy of the relevant attributes with its own throughput and storage charges. A table with several GSIs can cost multiples of the base table. Drop indexes you don't query, and project only the attributes each GSI actually needs.

What is the DynamoDB Standard-IA table class?

Standard-Infrequent Access lowers storage cost (~60% cheaper storage) in exchange for higher read/write costs. It's right for tables where storage dominates and access is infrequent — audit logs, older records — but wrong for hot tables where the higher throughput rates would outweigh the storage savings.

Does TTL save money on DynamoDB?

Yes, indirectly. TTL automatically deletes expired items at no cost, shrinking storage and the data GSIs replicate. For tables that accumulate transient data (sessions, events, caches), TTL prevents storage and index costs from growing unbounded.

How does C3X estimate DynamoDB cost?

C3X prices an aws_dynamodb_table from its capacity mode and provisioned throughput, with storage and request volume modeled as usage, so capacity-mode and GSI decisions show their cost before deployment.

What to do next

Capacity mode and provisioned throughput are in your Terraform, so the biggest lever is visible before deploy. C3X prices an aws_dynamodb_table from its capacity configuration, with storage and requests modeled as usage, so an over-provisioned table or GSI-heavy design shows its cost in review. The quickstart runs it in minutes.