Introduction

If you want DynamoDB to scale throughput automatically, the first decision is whether you should be using provisioned capacity at all. DynamoDB supports both on-demand and provisioned modes, and auto scaling applies specifically to provisioned read and write capacity on tables and global secondary indexes.

Choose the Capacity Model First

DynamoDB gives you two main options:

• 'on-demand, where AWS handles request scaling and you pay per request'
• 'provisioned, where you choose read and write capacity units and can attach auto scaling policies'

If traffic is highly unpredictable, on-demand mode is often simpler than configuring throughput targets manually. Auto scaling is most useful when you want the control of provisioned capacity but do not want to resize it by hand.

That distinction matters because auto scaling is not a universal switch. It is a way to manage provisioned capacity more intelligently, not a replacement for deciding which capacity mode fits the workload.

How Auto Scaling Works

DynamoDB auto scaling uses AWS Application Auto Scaling. You define:

• a minimum capacity
• a maximum capacity
• a target utilization percentage

AWS then adjusts provisioned capacity to keep consumed capacity near that target. A common starting point is around 70 percent utilization, which usually leaves some headroom while still using capacity efficiently.

This is not instant scaling for every burst. Capacity changes follow observed CloudWatch metrics and policy behavior, so short spikes still need existing headroom or a capacity mode that can absorb them more directly.

Configure It with the AWS CLI

To enable scaling for table read capacity, first register the table as a scalable target:

1aws application-autoscaling register-scalable-target \
2  --service-namespace dynamodb \
3  --resource-id table/Orders \
4  --scalable-dimension dynamodb:table:ReadCapacityUnits \
5  --min-capacity 5 \
6  --max-capacity 200

Then add a target-tracking policy:

1aws application-autoscaling put-scaling-policy \
2  --service-namespace dynamodb \
3  --resource-id table/Orders \
4  --scalable-dimension dynamodb:table:ReadCapacityUnits \
5  --policy-name OrdersReadPolicy \
6  --policy-type TargetTrackingScaling \
7  --target-tracking-scaling-policy-configuration '{
8    "TargetValue": 70.0,
9    "PredefinedMetricSpecification": {
10      "PredefinedMetricType": "DynamoDBReadCapacityUtilization"
11    },
12    "ScaleOutCooldown": 60,
13    "ScaleInCooldown": 60
14  }'

You would repeat the same pattern for write capacity and for each global secondary index that needs its own scaling behavior.

Remember That Indexes Scale Separately

A common production mistake is enabling auto scaling on the table but forgetting busy global secondary indexes. A table can look healthy while an index is still throttling reads or writes because it has its own capacity limits.

That means you should review:

• table read capacity
• table write capacity
• read-heavy indexes
• write-heavy indexes

Each of those may need different min, max, and target settings.

Tuning Advice

Good settings come from traffic history. Start with a minimum high enough for ordinary load, a maximum high enough for expected peaks, and a target utilization that leaves room for variation. Then watch throttling, consumed capacity, and cost.

If the workload is extremely spiky and scale-out still arrives too late, do not keep turning knobs forever. Either provision more headroom or switch to on-demand mode if the business case fits it better.

Common Pitfalls

• Using provisioned plus auto scaling when on-demand would be simpler.
• Setting the maximum capacity too low to help during real peaks.
• Forgetting to configure scaling for hot global secondary indexes.
• Expecting instant reaction to very short traffic spikes.
• Tuning only the target percentage without checking throttling and historical usage.

Summary

• DynamoDB auto scaling manages provisioned capacity, not on-demand mode.
• Choose the capacity model first based on traffic predictability and control needs.
• Configure min, max, and target utilization through Application Auto Scaling.
• Apply the same thinking to busy global secondary indexes.
• Tune from observed traffic and throttling data, not guesswork.