A practical guide to four DynamoDB settings—capacity mode, item sizing, DAX caching, and IA table class—that can cut spend by up to 80% without code rewrites or migrations.
4 DynamoDB Configuration Tweaks That Can Slash Your Bill

Running DynamoDB at scale often means a monthly invoice that feels out of control. The good news is that most of the levers that drive cost are hidden in plain sight, and they don’t require a full‑scale re‑architecture. Below we walk through four adjustments, show the math behind each, and point you to tools that make modeling easy.
1. Move From On‑Demand to Provisioned + Reserved Capacity
On‑demand capacity is attractive because you never have to forecast traffic. The trade‑off is a price tag that can be 7‑15 × higher than provisioned capacity, even after AWS’s recent price cut.
Example – a workload that sustains 10 k reads/s and 10 k writes/s 24 h a day:
| Mode | Annual Cost |
|---|---|
| On‑demand | ≈ $239 k |
| Provisioned (no reservation) | ≈ $71 k |
| Provisioned + Reserved (3‑year term) | ≈ $34 k |
The reserved tier assumes you can predict peak throughput and commit financially. If your traffic is erratic, provisioned capacity without reservation still offers a 3.3 × savings over on‑demand. The switch is a matter of updating the table’s capacity settings in the AWS console or via CloudFormation; no schema changes are needed.
Why it matters – A typical SaaS that runs on‑demand for a year can pay the same as a small startup’s entire server budget. The savings free up cash for product work rather than infrastructure.
2. Trim Item Sizes
DynamoDB charges writes per 1 KB and reads per 4 KB. An item that is 1.1 KB costs the same as a 2 KB item on a write, and a 5 KB item costs the same as a 8 KB item on a read. Small overshoots quickly balloon the bill.
Cost impact – Using the same 10 k RPS + 10 k WPS workload:
| Avg. item size | Approx. annual cost (on‑demand) |
|---|---|
| 1 KB | $239 k |
| 10 KB | $2 M |
| 100 KB | $20 M |
Typical culprits:
- Nested JSON with whitespace
- Redundant fields that never change
- Base64‑encoded blobs stored directly
- Long audit strings attached to every record
Practical steps:
- Compress JSON payloads with a fast algorithm like LZ4 before writing.
- Remove static metadata and move it to a separate table or to S3.
- Trim variable‑length strings (e.g., truncate logs, limit tag lengths).
- Consider a column‑oriented storage pattern for wide rows that are rarely accessed in full.
Even a 200‑byte reduction per item can translate to thousands of dollars per month when you’re writing millions of records each day.
3. Add DynamoDB Accelerator (DAX) for Hot Reads
If your workload is read‑heavy, DAX can act as an in‑memory front‑end that eliminates most read‑capacity‑unit (RCU) charges. A DAX cluster sits between your application and DynamoDB; cache hits bypass the database entirely.
Scenario – 80 k reads/s and 1 k writes/s, 24 h:
| Setup | Approx. annual cost |
|---|---|
| Pure on‑demand | $335 k |
| On‑demand + DAX (medium cluster, 3 × r5g.8xlarge) | $158 k |
The DAX cluster itself costs roughly $9 k/month. With a high cache‑hit rate (70 %+), the reduction in RCUs outweighs the cluster cost, delivering a net saving of over $150 k per year.
Additional benefit – Latency drops from milliseconds to microseconds, which can improve user experience for real‑time dashboards or recommendation engines.
4. Use the Infrequent Access (IA) Table Class for Cold Data
Not every table needs the fast‑access Standard class. For audit logs, historical snapshots, or lookup tables that are queried rarely, the Standard‑IA class reduces storage price from $0.25/GB to $0.10/GB—a 60 % reduction.
Caveats:
- Minimum item size of 100 bytes and a minimum billing duration apply.
- Read pricing is unchanged, so IA is unsuitable for tables that are scanned frequently.
When applied to a 10 TB archive table that is accessed only a few times per month, the annual storage cost drops from $2.5 M to $1 M.
Putting It All Together
The four tweaks are independent, but the biggest impact usually comes from the capacity mode change. A typical migration path looks like this:
- Switch to provisioned + reserved (quick console change).
- Audit item sizes and apply compression or schema pruning.
- Deploy DAX for any read‑heavy tables.
- Migrate cold tables to the IA class.
When combined, many teams report 50‑80 % reductions in their DynamoDB spend.
Model Your Savings
ScyllaDB offers a free Cost Calculator that lets you plug in your current read/write rates, item sizes, and desired capacity mode. It then compares DynamoDB pricing against ScyllaDB’s own offering, giving you a clear picture of where the biggest gaps lie.
Try it here: ScyllaDB Cost Calculator.
About the Author
The guide was prepared by the ScyllaDB engineering team, which focuses on high‑performance NoSQL solutions. Their work frequently surfaces in the community for practical cost‑optimization advice.
This article was originally published on HackerNoon and is reproduced under the author’s permission.

Comments
Please log in or register to join the discussion