Combining DynamoDB On‑Demand Mode with Auto‑Scaling to Handle Spiky Workloads

Problem: Spiky Workloads Cause Throttling and Over‑Provisioning Costs

When a DynamoDB table experiences sudden bursts of read or write traffic, a fixed provisioned capacity can lead to throttling errors. Over‑provisioning to avoid throttling wastes money during idle periods, while under‑provisioning degrades user experience. Teams often face the choice of constantly adjusting capacity or accepting occasional throttles.

Thesis: Use On‑Demand Mode with Auto‑Scaling Policies

DynamoDB’s on‑demand billing mode charges per request, eliminating the need to guess capacity. By pairing on‑demand with Application Auto Scaling policies that react to throttling metrics, the table can automatically add capacity during spikes and scale down when traffic eases, giving predictable performance without manual capacity planning.

Section 1: DynamoDB Capacity Modes

DynamoDB offers two billing modes:

• Provisioned: You specify read and write capacity units (RCUs/WCUs). You pay for the provisioned amount regardless of usage.
• On‑Demand: You pay per request; the service manages capacity behind the scenes.

On‑demand removes the need for capacity planning but still relies on internal scaling mechanisms that have a brief latency when traffic jumps sharply.

Section 2: Enabling Auto‑Scaling on an On‑Demand Table

Application Auto Scaling can adjust the internal capacity of an on‑demand table based on CloudWatch metrics. Useful metrics include:

• ThrottledRequests – counts requests rejected due to capacity limits.
• ConsumedReadCapacityUnits and ConsumedWriteCapacityUnits – actual usage.

A scaling policy can increase capacity when throttles exceed a threshold and decrease when usage stays low for a period.

Section 3: Worked Example – CLI Walkthrough

1. Create an on‑demand table (run in a terminal with AWS CLI v2, credentials that allow dynamodb:CreateTable):

   aws dynamodb create-table \
       --table-name OrdersTable \
       --attribute-definitions AttributeName=OrderId,AttributeType=S \
       --key-schema AttributeName=OrderId,KeyType=HASH \
       --billing-mode PAY_PER_REQUEST \
       --region us-east-1
   

2. Register the table as a scalable target (requires application-autoscaling:RegisterScalableTarget):

   aws application-autoscaling register-scalable-target \
       --service-namespace dynamodb \
       --resource-id table/OrdersTable \
       --scalable-dimension dynamodb:table:ReadCapacityUnits \
       --min-capacity 5 \
       --max-capacity 2000 \
       --region us-east-1
   

3. Create a scaling policy based on throttles (requires application-autoscaling:PutScalingPolicy and cloudwatch:PutMetricAlarm):

   aws application-autoscaling put-scaling-policy \
       --policy-name OrdersTableThrottlePolicy \
       --service-namespace dynamodb \
       --resource-id table/OrdersTable \
       --scalable-dimension dynamodb:table:ReadCapacityUnits \
       --policy-type TargetTrackingScaling \
       --target-tracking-scaling-policy-configuration file://throttle-config.json \
       --region us-east-1
   

   where throttle-config.json contains:

   {
     "TargetValue": 1.0,
     "PredefinedMetricSpecification": {
       "PredefinedMetricType": "DynamoDBReadCapacityUtilization"
     },
     "ScaleInCooldown": 60,
     "ScaleOutCooldown": 60
   }
   

4. Verify the setup (run aws dynamodb describe-table and aws application-autoscaling describe-scaling-policies):

   aws dynamodb describe-table --table-name OrdersTable --region us-east-1
   

   Check that BillingModeSummary.BillingMode shows PAY_PER_REQUEST and that the auto‑scaling target appears in the output of the describe‑scaling‑policies call.

Trade‑off and Limitation

While on‑demand eliminates over‑provisioning, at very high steady‑state throughput the per‑request price can exceed the cost of well‑sized provisioned capacity. Auto‑scaling also has a minimum adjustment step and a cooldown period (typically 60 seconds), so a sudden spike may cause a brief period of throttling before capacity catches up. Monitoring the ThrottledRequests CloudWatch metric is essential to verify that the policy reacts quickly enough.

Actionable Closing

To adopt this pattern:

1. Start with an on‑demand table for new workloads.
2. Create a scalable target and a target‑tracking policy that uses ThrottledRequests or utilization metrics.
3. Set alarms on throttling and cost (via AWS Cost Explorer) to ensure the trade‑off stays favorable.
4. Review the scaling cooldown values; lower them only if your application can tolerate faster capacity changes and your budget allows the potential extra cost.

By combining on‑demand billing with reactive auto‑scaling, you gain the cost‑efficiency of pay‑per‑request while reducing the operational burden of manual capacity management for spiky traffic patterns.