Can DynamoDB auto scale?

Yes. DynamoDB auto scaling uses Application Auto Scaling to adjust provisioned read and write capacity toward a target utilization (settable 20–90%, commonly 70%), within min/max bounds you define. Alternatively, on-demand capacity mode scales instantly to traffic with no configuration. Both keep tables responsive to changing load without manual capacity planning.

Provisioned auto scaling

You create a scaling policy per table (and per global secondary index) that sets:

• a target utilization (percent of provisioned capacity to aim for),
• minimum and maximum capacity units, and
• whether to scale reads, writes, or both.

CloudWatch alarms trigger Application Auto Scaling to raise or lower capacity as consumption crosses the target.

On-demand mode

On-demand capacity removes planning entirely: DynamoDB adjusts throughput to your traffic on its own — instantly accommodating up to double your previous traffic peak — and bills you per request. It is a good fit when traffic is bursty or hard to predict.

Which to choose

Provisioned with auto scaling usually costs less when traffic is stable and well understood; on-demand is simpler and better for unknown or bursty traffic.

Where target utilization stops paying

Target utilization is a price dial, and it has a floor below which auto scaling loses to on-demand outright.

In us-east-1 a write capacity unit costs $0.00065 an hour, so reserving one for a month costs $0.4745 and buys 2,628,000 writes. That is $0.00000018 per write against on-demand's $0.000000625, making provisioned capacity 3.46 times cheaper when every reserved unit gets used. Invert it and you get the break-even: provisioned stops paying below 28.9% average utilization. Reads work out to the same 28.9%, so this is a property of the pricing model rather than of one rate.

Sustained 1,000 writes a second of 1 KB items, priced with the pricing calculator:

The last two rows carry the lesson. A 20% target, the lowest AWS accepts, reserves five times your traffic and costs 44% more than paying per request for identical work. Every row above assumes auto scaling pins capacity exactly at the target, so treat them as best cases: real traffic wanders and the algorithm follows it late, which drags realized utilization under whatever you configured.

What the dial buys

Scale-up and scale-down are deliberately asymmetric, and that asymmetry is what the headroom pays for. AWS documents scale-up as triggering after consumed capacity breaches the target for two consecutive minutes and scale-down after 15 consecutive data points below it. The UpdateTable call that follows takes several more minutes, and anything above the old ceiling is throttled while it runs.

Decreases are rationed too. You start each UTC day with four and earn one an hour, never holding more than four, which caps you at 27 a day per table. Global secondary indexes get their own allowance.

So a high target saves real money and spends the buffer that covers those minutes. On-demand costs more per request and removes the trade entirely.

Go deeper

Compare them in on-demand vs provisioned capacity and estimate cost with the pricing calculator. Download DynoTable to read a table's size and item estimates in Table stats.

References

• Managing throughput capacity automatically with DynamoDB auto scaling — Amazon DynamoDB Developer Guide
• DynamoDB on-demand capacity mode — Amazon DynamoDB Developer Guide
• DynamoDB provisioned capacity mode — Amazon DynamoDB Developer Guide
• Quotas in Amazon DynamoDB — Amazon DynamoDB Developer Guide — the decrease allowance, re-checked 2026-07-28.

Last verified 2026-07-13 against the official AWS documentation linked above.

Break-even computed 2026-07-28 with our own pricing calculator over the us-east-1 rates it syncs from the AWS Price List API. The scaling delays and the decrease allowance were re-read from the AWS documentation linked above on the same date.