DynamoDB On-Demand vs Provisioned Capacity Mode
NoSQL capacity planning: DynamoDB On-Demand ($1.25/M WCU, $0.25/M RCU) vs Provisioned Capacity Mode ($0.00065/WCU-hr, $0.00013/RCU-hr). Calculate the exact autoscale crossover point.
Interactive Architecture Budget Estimator
Adjust your operational inputs to calculate unit costs and resource allocations across infrastructure components.
Itemized Architectural Unit Economics
Detailed mathematical cost model comparing raw resource units, provider markups, and optimization strategies.
| Architecture Component | Unit Cost (2026) | Benchmark Throughput / Sizing | Operational Notes & Trade-offs |
|---|---|---|---|
| On-Demand Mode (350 RPS / 120 WPS) | $448.50 / month | Billed purely on actual consumed read and write request units. Zero capacity management. | Ideal for unpredictable, spiky, or intermittent traffic |
| Provisioned Mode with Auto-Scaling | $148.92 / month | Configured with Target Tracking Auto-Scaling (70% target utilization). | 66% cheaper than On-Demand for steady, predictable traffic |
| Provisioned 1-Year Reserved Capacity | $96.80 / month | Commitment to steady baseline capacity with AWS Reserved Capacity discount. | 78% cheaper than On-Demand for established workloads |
| Data Storage (250 GB) | $62.50 / month | DynamoDB Standard table class data storage ($0.25 per GB-month). | Storage costs are identical across both capacity modes |
Production Implementation Code
DynamoDB Auto-Scaling Target Tracking Configuration (Terraform). Deploy directly into your production pipelines.
# dynamodb_autoscaling.tf - Configure Provisioned Auto-Scaling to save 65%
resource "aws_appautoscaling_target" "dynamodb_read_target" {
max_capacity = 1500
min_capacity = 50
resource_id = "table/production-user-sessions"
scalable_dimension = "dynamodb:table:ReadCapacityUnits"
service_namespace = "dynamodb"
}
resource "aws_appautoscaling_policy" "dynamodb_read_policy" {
name = "DynamoDBReadCapacityUtilization"
policy_type = "TargetTrackingScaling"
resource_id = aws_appautoscaling_target.dynamodb_read_target.resource_id
scalable_dimension = aws_appautoscaling_target.dynamodb_read_target.scalable_dimension
service_namespace = aws_appautoscaling_target.dynamodb_read_target.service_namespace
target_tracking_scaling_policy_configuration {
predefined_metric_specification {
predefined_metric_type = "DynamoDBReadCapacityUtilization"
}
target_value = 70.0 # Scales capacity up/down to maintain 70% utilization
}
}
Engineering Gotchas & Pitfalls
Critical architectural edge cases documented from real-world high-traffic deployments.
The Provisioned Throttling Cascade on Sudden Traffic Spikes
DynamoDB Auto-Scaling takes 2 to 5 minutes to detect traffic surges and adjust provisioned capacity. A viral marketing burst that arrives in 10 seconds will trigger `ProvisionedThroughputExceededException` errors unless On-Demand mode is used.
Hot Partition Throttling Regardless of Global Capacity
DynamoDB partitions data based on the partition key. Even with 10,000 provisioned WCUs globally, a single partition cannot exceed 1,000 WCUs or 3,000 RCUs. High traffic directed at a single key will throttle immediately.
Item Size Capacity Multipliers (4KB Reads / 1KB Writes)
One RCU reads an item up to 4KB. Reading an 8.5KB item consumes 3 RCUs. One WCU writes an item up to 1KB. Writing an 8.5KB item consumes 9 WCUs, multiplying capacity bills by 9x!
Frequently Asked Questions
Practical architectural questions answered with precise mathematical modeling.
Provisioned capacity breaks even with On-Demand when your steady utilization exceeds approximately 14% to 18%. If your application runs at a steady baseline with consistent traffic, Provisioned mode with Auto-Scaling saves 50% to 70%.
Yes. You can switch between On-Demand and Provisioned capacity modes up to four times per day with zero downtime and zero impact on running application queries.
Choose On-Demand for: new application launches with unknown traffic, spiky workloads (e.g. flash sales, event ticketing), development/test environments, and applications where traffic drops to near-zero overnight.
Related Architecture Guides & Tools
Explore related cost models and interactive simulators on CheckAPICost.
DynamoDB Capacity Economics: Auto Scaling Lag vs On-Demand Surcharges
Amazon DynamoDB offers two fundamentally different billing modes: Provisioned Capacity (billed per RCU/WCU hour with optional Application Auto Scaling) and On-Demand Mode (billed strictly per million Read/Write Request Units). On-Demand mode charges $1.25 per million write units and $0.25 per million read units. While it eliminates capacity planning and handles instant traffic spikes up to 2x previous peaks, its effective unit cost is 5x to 7x higher than steady-state Provisioned capacity ($0.00065 per WCU-hour equals ~$0.24 per million writes under full utilization).
Monthly Operating Cost Matrix: DynamoDB Workload Patterns (100M Reads / 20M Writes)
| Traffic Pattern | On-Demand Mode | Provisioned + Auto Scaling | Provisioned + DAX Cache | Reserved Capacity (1-Yr) |
|---|---|---|---|---|
| Spiky Batch / Serverless | $50.00 | $88.00 (Overprovisioned) | $210.00 (DAX node min) | N/A |
| Predictable SaaS (70% util) | $50.00 | $18.40 | $35.00 | $9.80 |
| High Scale (1B Reads / 200M Writes) | $500.00 | $162.00 | $115.00 (DAX absorbs 90%) | $84.00 |
Terraform: Provisioned Capacity with Application Auto Scaling
# Maintain 70% target utilization to prevent throttling while slashing on-demand bills
resource "aws_appautoscaling_target" "dynamodb_write_target" {
max_capacity = 500
min_capacity = 10
resource_id = "table/production_events"
scalable_dimension = "dynamodb:table:WriteCapacityUnits"
service_namespace = "dynamodb"
}
resource "aws_appautoscaling_policy" "dynamodb_write_policy" {
name = "DynamoDBWriteTracking"
policy_type = "TargetTrackingScaling"
resource_id = aws_appautoscaling_target.dynamodb_write_target.resource_id
scalable_dimension = aws_appautoscaling_target.dynamodb_write_target.scalable_dimension
service_namespace = aws_appautoscaling_target.dynamodb_write_target.service_namespace
target_tracking_scaling_policy_configuration {
target_value = 70.0
scale_in_cooldown = 300
scale_out_cooldown = 60
predefined_metric_specification {
predefined_metric_type = "DynamoDBWriteCapacityUtilization"
}
}
}Production DynamoDB Guardrails
- Hot Partition Throttling: Provisioned capacity divides evenly across physical partitions (each holding up to 10GB or 1,000 WCU / 3,000 RCU). If your partition key distributes traffic unevenly, a single hot key will throttle even if the table has hundreds of unused provisioned capacity units.
- DAX Caching Crossover: DynamoDB Accelerator (DAX) adds microsecond response times and shields the table from repetitive read spikes. A single `t3.medium` DAX node costs ~$38/month; it pays for itself once read volume exceeds 150 million queries monthly.
Engineering Q&A: DynamoDB Cost Architecture
Can a table switch freely between On-Demand and Provisioned modes?
Yes, but AWS limits switching to once every 24 hours. A common production strategy is running new services in On-Demand mode for the first 30 days to measure baseline traffic patterns, then switching to Provisioned with Target Tracking Auto Scaling once steady-state utilization is established.
How does item size impact DynamoDB billing units?
Writes are billed in 1 KB chunks (a 4.5 KB item consumes 5 WCUs), while reads are billed in 4 KB chunks (a 4.5 KB item consumes 2 RCUs). Storing uncompressed JSON blobs or large strings in DynamoDB rapidly multiplies capacity unit consumption. Compress large payloads with gzip or offload them to S3, storing only the S3 URL in DynamoDB.