Choosing DynamoDB On-Demand Capacity for Unpredictable Workloads

Introduction

When a DynamoDB table sees a sudden jump in traffic, the application can start receiving ProvisionedThroughputExceededException errors if the table's capacity is not ready. Over-provisioning to avoid this wastes money, while under-provisioning hurts reliability.

How On-Demand Scaling Works

In on-demand mode DynamoDB automatically adjusts read and write capacity to match the actual request rate. There is no need to set RCUs or WCUs, and the service scales up within seconds of a traffic increase. This eliminates the lag caused by Auto Scaling in provisioned mode, which can take minutes to react.

Cost Trade-offs

On-demand charges per request, typically about four times the cost of a provisioned request when reserved capacity is used. However, you only pay for what you consume, so idle periods cost nothing. For steady, high-volume workloads provisioned mode with auto scaling can save 20-30% compared to on-demand.

Worked Example: Switching a Table to On-Demand

Assume you have a table called SalesEvents that currently uses provisioned capacity. To change it to on-demand, run the following AWS CLI command (you need dynamodb:UpdateTable and dynamodb:DescribeTable permissions):

aws dynamodb update-table --table-name SalesEvents --billing-mode PAY_PER_REQUEST

After the command finishes, verify the change:

aws dynamodb describe-table --table-name SalesEvents --query 'TableDescription.BillingMode'

The expected output is the string PAY_PER_REQUEST. If you see PROVISIONED, the update did not apply; check the error message for permission issues.

Limitations to Keep in Mind

Even though on-demand scales quickly, DynamoDB enforces regional burst limits. A table can instantly handle up to roughly double its previous peak traffic. If a spike exceeds that, you may see throttling until the service catches up. Monitor the ConditionalCheckFailedRequests or UserErrors CloudWatch metrics to detect throttling.

For workloads with a constant high request rate, the per-request price of on-demand can become expensive. In such cases, consider switching back to provisioned mode with auto scaling and possibly reserved capacity to reduce cost.

Actionable Takeaway

Start new projects in on-demand mode to avoid capacity planning up front. After a few weeks of production data, examine the traffic pattern. If the workload is stable, evaluate a migration to provisioned mode with auto scaling to cut costs. You can revert the billing mode at any time with the same CLI command, substituting PROVISIONED and setting desired RCU/WCU values.