DynamoDB cost optimization: reduce read/write and storage drivers

DynamoDB costs typically scale with reads, writes, and stored bytes. The highest leverage savings come from reducing wasted reads/writes (especially scans) and controlling data and index amplification.

Step 0: identify your dominant driver

• Reads dominate: high read request volume, scan-heavy workloads, or strong consistency requirements.
• Writes dominate: high write volume or many secondary indexes.
• Storage dominates: large items, many projected attributes, or long-lived data without TTL.

1) Reduce read cost (avoid scans and oversized reads)

• Avoid scans: prefer query patterns that target a partition key and narrow sort key ranges.
• Use projection: return only needed attributes to reduce read bytes and item size amplification.
• Cache hot reads: app-level caching or edge caching reduces repeated reads.
• Control retries: timeouts and retries multiply read units during incidents.

2) Reduce write cost (control amplification)

• Minimize index count: each GSI can increase write work and stored bytes.
• Write smaller items: item size affects effective write units.
• Batch writes: reduce overhead and smooth spikes where possible.

Index and data model hygiene (often the real cost lever)

• Every GSI is a multiplier: treat new GSIs like new tables from a cost perspective.
• Project only what you need: avoid projecting large attributes into indexes by default.
• Avoid "scan to find": redesign access patterns so your hot paths are key-based queries.
• Separate analytics: move heavy exploratory workloads to a system designed for scans, not DynamoDB.

3) Reduce storage cost (data shape and retention)

• Use TTL intentionally: expire data that does not need to be retained indefinitely.
• Store references: keep large blobs in object storage and store only pointers in DynamoDB.
• Control projection: indexes that project many attributes can multiply storage.

4) Choose the right capacity mode (and validate)

• Spiky workloads: on-demand can be simpler, but still needs request volume validation.
• Predictable workloads: provisioned + autoscaling can reduce cost when you can forecast.
• Busy month modeling: include deploy/incident spikes so you don’t under-provision and trigger retries.

Validation checklist

• Validate top queries: what percent are scans vs targeted queries?
• Validate item size distribution (average and p95) before and after changes.
• Validate GSI count and projections; quantify write amplification from indexes.
• After changes, compare a real week of usage and confirm incidents do not regress.

Sources

• DynamoDB pricing: aws.amazon.com/dynamodb/pricing
• Best practices and design patterns: docs.aws.amazon.com

Related guides

FAQ