DynamoDB Pricing Strategy: Capacity Mode, GSIs, and Reserved Capacity
DynamoDB has the steepest cost cliff of any AWS database. On-demand at scale is 5 to 10x the cost of provisioned with reserved capacity, and table design choices that look harmless in dev compound into seven-figure waste in production.
DynamoDB is the AWS database where the cost difference between competent and incompetent operation is largest. We have audited estates where switching capacity mode and trimming GSIs cut $1.4M annual spend by 78 percent without touching application code. The leverage comes from understanding what you actually pay for: not the data, but the read and write capacity units consumed against it.
The two capacity modes
| Mode | How it bills | Best for |
|---|---|---|
| On-demand | Per read / write request | Unpredictable traffic, low-volume tables, dev/QA, spike absorption |
| Provisioned | Per WCU/RCU per hour reserved | Steady-state production, predictable patterns, anything at scale |
The break-even rule: at sustained utilisation above roughly 18 percent of peak capacity, provisioned with auto-scaling beats on-demand. Most production DynamoDB workloads run at 30 to 60 percent average utilisation, so provisioned is the right answer.
Provisioned capacity with auto-scaling
Provisioned mode lets you set baseline WCU and RCU and enable auto-scaling to add capacity as utilisation rises. The configuration that works for most production tables:
- Baseline WCU/RCU at the 25th-percentile of recent traffic.
- Auto-scaling target at 70 percent utilisation.
- Auto-scaling maximum at 5 to 10x baseline.
- 1- or 3-year reserved capacity covering 60 to 80 percent of baseline.
This configuration keeps you paying for capacity you use while absorbing spikes via auto-scaling, and locks in long-term discount via reserved capacity.
Reserved capacity economics
DynamoDB Reserved Capacity is the most overlooked discount in the AWS catalogue. It applies to provisioned WCU and RCU only; on-demand and replicated GSI capacity is not eligible. Rates:
| Term | Approximate savings off provisioned |
|---|---|
| 1 year | 50 to 55 percent |
| 3 year | 75 to 80 percent |
Combined with the 7x advantage of provisioned over on-demand, 3-year reserved capacity is roughly 35x cheaper than on-demand for the same throughput.
See DynamoDB reserved capacity for the detailed buying strategy.
Global Secondary Indexes (GSIs)
Every GSI you attach to a table replicates the base table data into a separately-billed index with its own WCU/RCU consumption. The GSI bill is additive to the base table bill. Two common waste patterns:
- GSIs created and never used. Audit usage with CloudWatch
ConsumedReadCapacityUnitsandConsumedWriteCapacityUnitsper index. Unused GSIs cost the same as used ones; delete them. - GSIs with unnecessary projections. KEYS_ONLY projects only the primary key; INCLUDE projects specific attributes; ALL projects everything. ALL is the default and the most expensive. Reduce projection scope wherever query patterns allow.
The discipline: every GSI quarterly review with usage report. 20 to 40 percent of DynamoDB spend at enterprise scale is GSI waste.
Item size optimisation
DynamoDB capacity unit consumption scales with item size. A 4 KB read consumes 1 RCU; a 12 KB read consumes 3 RCUs. A 1 KB write consumes 1 WCU; a 4 KB write consumes 4 WCUs.
Practical optimisation:
- Compress large attributes. Store gzipped binary data for large text fields.
- Move blob storage to S3. Anything above 100 KB is almost always cheaper to store in S3 with a pointer in DynamoDB.
- Avoid duplicating data in items. Denormalisation has cost.
- Use BatchGetItem and BatchWriteItem. Batched requests are cheaper than individual request round-trips.
Storage class: Standard versus Standard-IA
DynamoDB Standard-IA (Infrequent Access) costs 60 percent less than Standard for storage but 25 percent more for read/write requests. The break-even:
- Tables where item access frequency is below roughly once per 30 days per item.
- Audit log tables, historical event stores, archived data.
- Watch out: warming up a Standard-IA table with sudden traffic is more expensive than warming a Standard table.
Global Tables and cross-region replication
DynamoDB Global Tables replicate writes to additional regions. Each replica region bills full provisioned (or on-demand) capacity plus the standard data transfer charge for the replication traffic. Effective cost: 2x for two regions, 3x for three regions, and so on, plus inter-region transfer.
The decision discipline: justify each additional region against measured user latency or compliance requirement, not aspiration. Most Global Tables deployments include at least one region whose traffic profile does not justify the cost.
The EDP private pricing layer
DynamoDB is one of the easier AWS services to negotiate custom pricing on at scale. The threshold for custom pricing conversations is roughly $50K/month sustained DynamoDB spend. The negotiable items:
- Custom per-request rates on on-demand. AWS will discount on-demand rates 15 to 35 percent for sustained high-volume on-demand consumers.
- Custom WCU/RCU rates on provisioned. Below standard reserved capacity rates for very large committed pools.
- Global Tables replication transfer discounts. Cross-region replication data transfer is negotiable at multi-PB scale.
- Backup storage discounts. Continuous backup (PITR) and on-demand backup storage above the free allocation.
Case study: $1.4M DynamoDB estate
A consumer tech customer with $1.4M annual DynamoDB spend across 47 tables. Findings:
- 34 of 47 tables on on-demand. Audit showed 22 of those ran at sustained utilisation above 30 percent.
- 119 GSIs in total across the estate. CloudWatch analysis flagged 38 with zero traffic in the prior 90 days.
- Reserved capacity coverage: 4 percent of provisioned spend.
- 17 tables with ALL projection on GSIs where KEYS_ONLY would have sufficed.
Interventions:
- Switched 22 tables from on-demand to provisioned with auto-scaling. $510K annualised saving.
- Deleted 38 unused GSIs. $187K annualised saving.
- Reduced ALL to KEYS_ONLY projection on 17 GSIs. $66K annualised saving.
- Purchased 3-year reserved capacity covering 70 percent of new provisioned baseline. $246K annualised saving.
- Negotiated custom on-demand pricing on remaining on-demand workloads as part of EDP renewal. $98K annualised saving.
Combined annual run-rate dropped from $1.4M to $293K, a 79 percent reduction.
Action checklist
- Inventory every DynamoDB table. Classify capacity mode and measure average utilisation.
- Switch sustained-utilisation tables from on-demand to provisioned with auto-scaling.
- Audit every GSI for traffic and projection scope. Delete unused; reduce projection where possible.
- Move large-item workloads to S3 pointer model.
- Purchase reserved capacity covering 60 to 80 percent of provisioned baseline.
- Audit Global Tables; justify each replica region.
- For spend above $50K/month, scope custom DynamoDB pricing into EDP renewal.
- Contact our advisory team for a DynamoDB cost audit benchmarked against $2.4B+ of reviewed AWS spend.
DynamoDB rewards disciplined operation more than any other AWS database service. See our AWS database cost strategy guide for how DynamoDB fits the broader database picture, and DynamoDB reserved capacity for the reserved buying strategy.