AWSData & storage6 min read

Compare DynamoDB on-demand and provisioned capacity

Sources checked September 7, 2026Varies by scope
On this page
THE SHORT ANSWER

Prefer on-demand for unpredictable or sharply variable traffic. Compare provisioned capacity for stable, predictable workloads where allocated read and write units can stay close to consumption without increasing throttling.

Why this is worth a look

On-demand uses pay-per-request billing for consumed read and write requests. Provisioned mode bills the capacity configured for the table, whether requests consume all of it or not, and can use auto scaling. Review the table and each global secondary index (GSI) separately because CloudWatch exposes their capacity metrics separately. Normalize item size, read consistency, and transactional operations before comparing units. Eventually consistent reads use half the read units of strongly consistent reads for the same rounded size, while transactional reads and writes use more.

Run this check

CHECKLIST

A read-only review checklist for DynamoDB settings and CloudWatch metrics. It defines the AWS account, Region, table, GSI, units, permissions, and representative review period to compare capacity modes.

DynamoDB capacity mode comparison
Scope and access
[ ] Record the AWS account, Region, table name, and representative review period. Use a fine-grained period such as 14 days, and include known weekly, monthly, or seasonal peaks when relevant.
[ ] Use read access to DynamoDB and CloudWatch. Use your applicable effective DynamoDB rates for the Region and contract, including eligible reserved capacity where relevant.

Supported inventory
[ ] Record whether the table uses on-demand or provisioned capacity.
[ ] Record table read and write throughput, and repeat the review for every global secondary index (GSI).
[ ] For provisioned capacity, record auto scaling minimum capacity, maximum capacity, and target utilization.
[ ] For on-demand capacity, record any configured maximum read or write throughput for the table and each GSI.
[ ] Record eligible reserved capacity that applies to provisioned read or write capacity.

CloudWatch review
[ ] At one-minute intervals, review ConsumedReadCapacityUnits and ConsumedWriteCapacityUnits for the table.
[ ] For each GSI, specify both TableName and GlobalSecondaryIndexName when reviewing consumed and provisioned capacity metrics.
[ ] For provisioned capacity, review ProvisionedReadCapacityUnits and ProvisionedWriteCapacityUnits for the table and each GSI.
[ ] Review ReadThrottleEvents and WriteThrottleEvents. Also review ReadProvisionedThroughputThrottleEvents and ReadMaxOnDemandThroughputThrottleEvents where applicable.

Normalize and compare
[ ] Document item sizes, read consistency, and transactional operations. Reads round to 4 KB boundaries and writes to 1 KB boundaries.
[ ] Compare consumed read and write request units under on-demand billing with time-weighted provisioned read and write capacity under provisioned billing.
[ ] Apply your applicable effective rates, then consider non-throughput charges separately when they apply. Do not assume public retail rates equal your effective bill rate.

How to confirm it

  1. 01

    Set the review scope

    Record the AWS account, Region, table, and representative period. Use a fine-grained period such as 14 days, and include known weekly, monthly, or seasonal peaks when they matter to the decision.

  2. 02

    Inventory supported settings

    Record the table's on-demand or provisioned mode, table read and write throughput, every GSI's throughput, auto scaling minimum, maximum and target utilization for provisioned capacity, on-demand maximum throughput, and eligible reserved capacity.

  3. 03

    Review one-minute metrics

    In CloudWatch, review consumed read and write capacity unit metrics at one-minute intervals. Review provisioned capacity when applicable, and inspect table metrics plus each GSI using both TableName and GlobalSecondaryIndexName. Check ReadThrottleEvents, WriteThrottleEvents, and the documented provisioned-throughput and maximum-on-demand read throttle metrics where applicable.

  4. 04

    Normalize and price

    Document item sizes, read consistency, and transactions before comparing units. Reads round to 4 KB boundaries and writes to 1 KB boundaries. Compare pay-per-request consumed units with time-weighted provisioned capacity using your applicable effective regional and contractual rates, including eligible reserved capacity.

  5. 05

    Check switching constraints

    Before changing mode, confirm the documented switching rule: provisioned to on-demand is limited to four changes in a rolling 24-hour window, while on-demand to provisioned can occur at any time. Check maximum-throughput settings because they can bound usage and may cause throttling.

Before making changes

This is a planning comparison, not a bill calculation. CloudWatch aggregates these metrics at one-minute intervals, so the review cannot show the timing or shape of activity within each minute. Auto scaling evaluates consecutive minutes, alarms can be delayed, and capacity updates take several minutes, during which requests above previous provisioned capacity can be throttled. Treat item size, consistency, transactions, effective rates, eligible reserved capacity, and any applicable non-throughput charges as explicit assumptions. The site does not inspect your AWS account or bill.

Defer a mode switch during a controlled migration or while testing has already fixed the mode. Continue monitoring consumed capacity and throttling, then revisit the comparison when that constraint ends.

Primary sources