DynamoDB Cost Optimization

Cost optimization means paying only for the capacity and storage your application needs. DynamoDB bills for reads, writes, storage, backups, and data transfer. Small design choices change those bills substantially over time.

The Electricity Bill Picture

A household lowers its electricity bill by switching off unused lights, choosing efficient appliances, and picking the right power plan. DynamoDB savings follow the same logic. Remove waste, use efficient operations, and choose the right pricing option.

Where the Money Goes

Check the AWS pricing page for current rates in your Region. Prices change over time and differ between Regions.

Understand Capacity Unit Math

• One read unit covers one strongly consistent read of up to 4 KB.
• An eventually consistent read costs half a read unit for up to 4 KB.
• A transactional read costs double a strongly consistent read.
• One write unit covers one write of up to 1 KB.

An item of 9 KB needs three read units for a strongly consistent read, because DynamoDB rounds up to the next 4 KB block.

Strategy 1: Choose the Right Capacity Mode

On-demand mode charges per request and suits unpredictable or spiky traffic. Provisioned mode charges for reserved capacity and suits steady traffic. Reserved capacity discounts apply to provisioned tables with a committed term. Review each table every few months, because traffic patterns change.

Strategy 2: Pick the Right Table Class

DynamoDB offers two table classes. Standard suits most workloads. Standard-Infrequent Access charges less for storage and more for requests. A table that stores large volumes of rarely read data, such as old logs or archives, often costs less in Standard-IA.

Storage-heavy, rarely read   → Standard-IA
Request-heavy, frequently read → Standard

Strategy 3: Shrink Your Items

Item size drives both storage and capacity usage. Attribute names count toward the item size, so very long names waste space across millions of items.

Long names:   "customerEmailAddress", "orderCreationTimestamp"
Short names:  "email", "created"

Store large objects such as images and documents in Amazon S3, and keep only the S3 location in DynamoDB. Compress large text values before storing them.

Strategy 4: Read Efficiently

• Use Query instead of Scan. A Scan reads and charges for every item.
• Use eventually consistent reads wherever the application can tolerate a short delay.
• Request only the attributes you need with a projection expression.
• Remember that a filter expression runs after the read, so filtering does not reduce read cost.

Strategy 5: Control Index Costs

Every index duplicates data, and every write to the table also writes to each index. Project only the attributes that queries need instead of ALL. A sparse index, which contains only items that have the index key attribute, stays small and cheap.

Strategy 6: Delete Data Automatically

TTL removes expired items without charging write capacity. Short-lived data such as sessions and temporary codes should always carry a TTL attribute.

Strategy 7: Scale Automatically

Auto scaling adjusts provisioned capacity as traffic rises and falls. The setting avoids paying for peak capacity around the clock.

Diagram: Cost Review Flow

Review monthly bill
    │
    ├─ High read cost  → find Scans, use Query, cache with DAX
    ├─ High write cost → batch design, trim indexes, shrink items
    ├─ High storage    → compress, move blobs to S3, try Standard-IA, add TTL
    └─ Idle capacity   → lower provisioned units or switch capacity mode

Summary

• Reads, writes, storage, backups, and transfer make up the DynamoDB bill.
• Match the capacity mode and table class to your traffic and data.
• Smaller items, lean indexes, and Query-based reads reduce usage.
• TTL and auto scaling remove waste without manual effort.
• Review the bill regularly, because access patterns change.