DynamoDB On-Demand vs. Provisioned Capacity Cost Traps

Q: Can we safely switch between On-Demand and Provisioned mode without downtime?

Yes, DynamoDB allows switching table billing modes seamlessly in the background with zero impact on active read/write queries.

Q: How does DynamoDB DAX (Accelerator) impact read costs?

DAX provides an in-memory microsecond cache cluster, absorbing millions of repetitive read queries and reducing consumed table RCUs to zero for cache hits.

Q: What is the best way to handle DynamoDB table Scans safely?

Never use Scans in client-facing requests; export data to S3 via DynamoDB native continuous backup and query with Athena for bulk analytics.

Stack: FINOPS INFRASTRUCTURE STACK →Staff (L6-L7)anti-pattern

THE SHORT ANSWER

On-Demand mode charges a 5x-7x premium over provisioned capacity for steady workloads; combining this with large item sizes (>1KB), un-indexed full table Scans, and multiple Global Secondary Indexes (GSIs) multiplies every write operation into multiple expensive billable units.

Engineering Handbook & Failure Dynamics

1. Underlying Mechanism

DynamoDB bills writes in 1KB increments (1 WCU per 1KB/sec) and reads in 4KB increments (1 RCU per 4KB/sec strongly consistent). In Provisioned mode with Auto Scaling, 1 WCU costs ~$0.00065/hr (~$0.47/mo). In On-Demand mode, 1 million Write Request Units cost $1.25, which is equivalent to ~$0.00173/hr for equivalent steady throughput (nearly 5.5x more expensive). Furthermore, every write to a table with 4 GSIs consumes 1 base write + 4 GSI writes (5x write multiplication).

2. Appropriate Use Context

Use On-Demand for brand-new tables with unknown traffic patterns, highly sporadic workloads (<15% duty cycle), or critical spikes where capacity cannot be predicted. Switch to Provisioned with Auto Scaling once baseline traffic reaches steady state.

3. Production Failure Modes

An analytics cron job performs an hourly un-indexed `Scan` operation across a 50-million item DynamoDB On-Demand table storing 10KB payloads. Each scan consumes 125,000 Read Request Units per minute, resulting in an unexpected $18,000 monthly database invoice.

4. Diagnostic Signals & Telemetry

1. AWS Cost Explorer shows DynamoDB `PayPerRequestThroughput` as the dominant database line item. 2. High `ConsumedWriteCapacityUnits` on GSIs compared to base table metrics. 3. Average item size exceeding 1,024 bytes triggering double RCU/WCU metering.

5. Prevention & Safeguards

1. Migrate steady production tables to Provisioned Capacity with Application Auto Scaling set to 70% target utilization. 2. Use GSI projection type `KEYS_ONLY` or `INCLUDE` rather than `ALL` to avoid replicating unnecessary large attributes. 3. Compress large JSON payloads (via zlib/snappy) before storing in DynamoDB binary attributes.

6. Architectural Trade-offs

Provisioned capacity requires configuring auto-scaling thresholds and warm-up headroom in exchange for reducing monthly DynamoDB costs by 70-80%.

Case Study (TinyCTO In-Field Example)

TinyCTO's user session table was operating in On-Demand mode, processing 4,000 writes/sec with 3 GSIs. Monthly cost was $32,400. Engineering optimized GSI projections to only index essential sorting keys and switched the table to Provisioned Capacity with 70% target Auto Scaling. Monthly cost dropped to $5,800, saving $319,200 annually.

Interactive Concept Drills

3 Cards

What is the cost ratio between DynamoDB On-Demand and Provisioned capacity for steady workloads?

On-Demand is approximately 5 to 7 times more expensive than Provisioned capacity with auto-scaling for steady 24/7 traffic.

How does item size impact DynamoDB write billing?

Writes are metered in 1KB increments; a 1.05KB item consumes 2 WCUs, instantly doubling the write cost compared to a 0.95KB item.

Why do Global Secondary Indexes (GSIs) amplify DynamoDB costs?

Every write or update to an item that modifies an indexed attribute triggers an automatic corresponding write to each relevant GSI.