When to Choose DynamoDB On-Demand Capacity Mode: A Practical Guide

Problem: Unpredictable Traffic Leads to Over‑Provisioning or Throttling

When an application’s request rate changes minute‑by‑minute, a DynamoDB table set to Provisioned capacity can either waste money on idle read/write units or throttle legitimate traffic when the burst exceeds the configured capacity.

Thesis: On‑Demand Removes Capacity Planning but Requires Cost Vigilance

Switching to On‑Demand (PAY_PER_REQUEST) lets the service automatically allocate the read and write capacity needed for each request, eliminating the need to guess peak usage. The trade‑off is a higher per‑request price that can become expensive under sustained load.

Worked Example: Moving a Table to On‑Demand

1. Ensure you have the IAM permissions dynamodb:UpdateTable and dynamodb:DescribeTable.
2. Run the update command (replace MyTable with your table name):

aws dynamodb update-table \\n    --table-name MyTable \\n    --billing-mode PAY_PER_REQUEST

1. Verify the change:

aws dynamodb describe-table \\n    --table-name MyTable \\n    --query Table.BillingModeSummary.BillingMode

The command should return PAY_PER_REQUEST. No data is moved or copied, so the operation completes in seconds without downtime.

Monitoring Cost and Performance

• Use AWS Cost Explorer to view the DynamoDB-OnDemand-BackendRequests metric and compare it to the previous provisioned cost over a similar traffic window.
• Enable CloudWatch metrics SuccessfulRequestLatency and ThrottledRequests to confirm latency stays consistent and throttling drops to zero.
• Set a budget alarm on the EstimatedCharges metric for DynamoDB to catch unexpected spikes.

Trade‑offs and Limitations

• Per‑request pricing can be 10×–100× higher than the equivalent provisioned rate when traffic stays high for extended periods.
• Legacy IAM policies that condition on dynamodb:ReadCapacityUnits or dynamodb:WriteCapacityUnits no longer apply; you must rewrite them to rely on action‑based conditions.
• Adaptive capacity helps with bursty traffic, but a sudden, sustained surge will still drive up costs proportionally.

Actionable Closing

If your workload exhibits unpredictable, spiky traffic and you can tolerate a higher per‑request price, switch to On‑Demand now:

1. Run the update command above during a low‑traffic window.
2. Verify the billing mode with the describe-table command.
3. Configure a Cost Explorer report and a CloudWatch alarm for throttling and cost.
4. Re‑evaluate after 4–6 weeks; if the average request rate stabilizes, consider moving back to Provisioned with auto‑scaling to reduce expenses.

To roll back, execute:

aws dynamodb update-table \\n    --table-name MyTable \\n    --billing-mode PROVISIONED \\n    --read-capacity-unit 5 \\n    --write-capacity-unit 5

Replace the capacity numbers with values that match your baseline usage, then monitor for throttling.