DynamoDB On-Demand vs Provisioned Capacity

DynamoDB on-demand charges for the read and write units you consume; provisioned mode charges for the capacity you allocate, including idle capacity. At current US East (N. Virginia) Standard-table prices, provisioned throughput becomes cheaper at about 29% average utilization, before free allowances and discounts. On-demand is AWS's recommendation for most workloads, while predictable, consistently utilized workloads can cost less with provisioned capacity and auto scaling.

Compare the modes

Both modes use the same data model and offer the same DynamoDB durability, consistency options and service-level agreement. They can both throttle. Neither repairs an inefficient scan, a hot key or excess index writes. The capacity modes guide explains the terminology across throughput, billing and scaling.

Understand the units before comparing prices

A standard write uses one unit per 1 KB, rounded up. A strongly consistent read uses one unit per 4 KB, while an eventually consistent read uses half that amount. A transactional write or read uses twice the units of its ordinary write or strongly consistent read counterpart.

In provisioned mode, one WCU supports one write per second of up to 1 KB; one RCU supports one strongly consistent read per second of up to 4 KB. On-demand WRUs and RRUs measure the corresponding consumed operations rather than reserved throughput. A 6 KB item therefore changes the math: writing it needs six write units, while a strongly consistent point read needs two read units.

Estimate tables and GSIs separately, including projected index item size. Use the item size and capacity calculator and choose the read consistency your application actually needs.

Current prices and the utilization break-even

These are us-east-1, Standard table class rates checked on October 23, 2026. Storage, indexes, backups, replication and other features are additional. The examples below exclude free allowances, commitment discounts and taxes so the billing modes can be compared directly.

AWS cut on-demand throughput prices by 50%, effective November 1, 2024. Older comparisons using $1.25 per million writes and $0.25 per million reads exaggerate the current premium. Use the AWS pricing page or the DynamoDB pricing calculator for your Region and table class.

One WCU used continuously produces 3,600 write units per hour. At full utilization, provisioned writes cost approximately $0.181 per million units, and provisioned strongly consistent reads cost approximately $0.0361 per million units. On-demand costs about 3.46 times as much per fully utilized unit.

For a write capacity unit with average utilization u, the hourly comparison is:

Provisioned = $0.00065
On-demand  = 3,600 × u × $0.625 / 1,000,000
Break-even u = 0.00065 / (3,600 × 0.625 / 1,000,000)
             = 0.2889, or about 29%
Provisioned = $0.00065
On-demand  = 3,600 × u × $0.625 / 1,000,000
Break-even u = 0.00065 / (3,600 × 0.625 / 1,000,000)
             = 0.2889, or about 29%

Reads have the same break-even at these prices. Below that utilization, paying only for consumed request units is cheaper. Above it, provisioned throughput is cheaper before discounts and other costs. This is measured utilization across the billed capacity-hours, not the target percentage configured in an auto scaling policy.

Worked example: a steady workload

Assume a 30-day month, or 720 hours, with 70 writes/s of items up to 1 KB and 700 strongly consistent reads/s of items up to 4 KB. There are no GSIs or transactions in this example. Provision 100 WCU and 1,000 RCU, giving 70% utilization and headroom above the average demand.

Provisioned saves $199.80, approximately 59%, for this sustained workload. Auto scaling can maintain the same general utilization as demand changes gradually, but measured billing may differ because capacity uses whole units and scaling takes time.

Changing every read to eventual consistency would halve the required read units in either mode. Adding a GSI would add its own throughput and storage. Those choices matter independently of the billing-mode decision.

Worked example: a spiky workload

Now assume 700 writes/s and 7,000 strongly consistent reads/s for one hour each day, with no requests during the remaining 23 hours. Keep the same item sizes and 30-day month. The busy period totals 30 hours, producing 75.6 million WRUs and 756 million RRUs.

The always-ready provisioned case averages only about 2.9% utilization, despite reaching 70% utilization during the peak hour. On-demand wins by avoiding the idle allocation.

The scheduled case illustrates a different outcome when the burst is predictable. Its peak allocation costs $58.50, and its idle minimum costs about $0.54. This is an idealized lower-bound comparison: a real schedule needs lead time and may retain capacity after the peak, so its bill will be higher. Reactive auto scaling cannot be assumed to achieve this schedule or immediately absorb an unexpected jump from near-zero traffic.

The lesson is to compare capacity over time. An average request count alone hides the difference between a steady workload and a short burst that requires hours of provisioned headroom.

How provisioned auto scaling behaves

DynamoDB auto scaling uses Application Auto Scaling to change provisioned capacity. Configure independent minimums, maximums and utilization targets for reads and writes, and do the same for each GSI. Supported target utilization ranges from 20% to 90%. A 70% target means the system aims to keep consumed capacity near 70% of allocated capacity over time.

The auto scaling documentation describes the response timing:

1. DynamoDB publishes consumed-capacity metrics in one-minute periods.
2. Consumption above target for two consecutive minutes can trigger scale-up.
3. CloudWatch alarm evaluation may add a few minutes, and the UpdateTable operation takes additional time.
4. Scale-down can trigger after 15 consecutive data points below target, subject to the decrease allowance.

Consequently, scale-up is not guaranteed within two minutes. Requests can throttle against the previous allocation while the update is pending. Very short spikes may end before auto scaling reacts. Burst capacity can help, but it should not replace capacity planning for a known launch.

How often can DynamoDB scale down?

The default is up to 27 provisioned decreases per UTC day for each table or GSI. The allowance starts at four; one becomes available each hour, with at most four available at a time. Tables and GSIs have independent allowances. The service quotas documentation defines these rules; auto scaling still operates within them.

Set a minimum that covers expected baseline demand and a maximum that permits the expected peak. A high minimum can leave measured utilization far below the target overnight. A low maximum can cause throttling even when the policy correctly requests more capacity.

An under-provisioned GSI can throttle base-table writes. Do not blindly copy the table's read and write settings to every index: projected item sizes and access patterns differ. Schedule increases before predictable events and monitor consumed and provisioned capacity together.

On-demand scaling and warm throughput

On-demand instantly accommodates up to twice the table's previous peak. Exceeding twice that peak within 30 minutes can cause throttling while it adapts. New tables start with warm capacity corresponding to up to 12,000 read units/s and 4,000 write units/s, with actual request counts depending on item size and consistency. See AWS's on-demand scaling rules.

Warm throughput is the read and write rate a table or GSI can handle immediately. It is visible for both capacity modes, grows as DynamoDB adapts, and can be raised before a planned peak. Provisioned capacity must still be sufficient in provisioned mode; pre-warming does not replace the allocated capacity or waive request charges.

Default warm throughput has no separate charge. Explicitly raising it incurs a one-time fee for the increase. At the listed us-east-1 rates, raising warm read throughput from 12,000 to 100,000 units/s costs $11.44, calculated as 88,000 × $0.00013. Global tables apply pre-warming and its charge in each replica Region. Check the warm throughput documentation before scheduling a large event.

Warm throughput does not eliminate hot-partition constraints. The table can have ample aggregate capacity while a single key receives too much traffic.

Maximum throughput as an on-demand cost control

You can set independent maximum read and write throughput targets on an on-demand table or GSI. Requests above a configured target can be throttled. Without a configured maximum, service quotas still apply; the default table/GSI quota is 40,000 read units/s and 40,000 write units/s, and can be increased.

AWS documents maximum throughput as a best-effort target, not a guaranteed ceiling, because burst capacity can temporarily allow additional traffic. It is also not a hard dollar budget: storage, backups, replicated writes and other charges continue separately. Use billing alerts as well as the maximum-throughput setting.

Distinguish three separate numbers when diagnosing throttling: the service quota, your configured maximum and warm throughput. Raising one does not automatically change the others.

Reserved capacity and Database Savings Plans

Reserved capacity can reduce eligible provisioned Standard-table throughput costs by up to 54% for one year or up to 77% for three years. Three-year availability is limited to certain Regions. Reservations are purchased in blocks of 100 RCU or WCU, and cover eligible provisioned capacity for tables and GSIs. They do not cover on-demand units, Standard-IA capacity or replicated write capacity.

Reserved capacity is a billing commitment, not a scaling policy. You still configure enough live capacity and pay for usage beyond the reservation. Reserve a dependable baseline rather than a temporary peak, and include the upfront charge when comparing effective rates.

Database Savings Plans use a one-year spending commitment and offer up to 18% off on-demand throughput and up to 12% off provisioned throughput, with flexibility across eligible AWS database services and Regions. Reserved capacity applies first; the same usage does not receive both discounts. Recalculate the break-even with your actual eligible rates instead of applying the undiscounted 29% threshold to every commitment scenario.

Switching capacity modes

The table and its indexes share a capacity mode. Switching does not require copying data. To change an existing table to on-demand with AWS SDK for JavaScript v3:

import { DynamoDBClient, UpdateTableCommand } from "@aws-sdk/client-dynamodb"

const client = new DynamoDBClient({})
await client.send(new UpdateTableCommand({
  TableName: "Orders",
  BillingMode: "PAY_PER_REQUEST",
}))
import { DynamoDBClient, UpdateTableCommand } from "@aws-sdk/client-dynamodb"

const client = new DynamoDBClient({})
await client.send(new UpdateTableCommand({
  TableName: "Orders",
  BillingMode: "PAY_PER_REQUEST",
}))

You may switch from provisioned to on-demand up to four times in a rolling 24-hour window. Switching back to provisioned is allowed at any time, subject to table update state, and requires appropriate table and GSI throughput settings. Wait for the update to complete before sending another incompatible table change.

Review auto scaling configuration and any billing commitments before switching. A reservation does not disappear because its table changes mode, and a change to provisioned mode needs enough capacity to serve the current traffic immediately.

When each mode wins

Choose on-demand when demand is uncertain, requests are intermittent, peak timing is unpredictable, or the operational cost of managing capacity outweighs the likely savings. It is a useful starting point while you gather production measurements. An idle on-demand table has no throughput charge, although its stored data and enabled features can still cost money.

Choose provisioned with auto scaling when representative measurements show sustained utilization above the relevant break-even and demand changes slowly enough for the policy to respond. It also fits predictable events that you can prepare for with scheduled scaling, and stable baselines that justify commitment discounts.

For either mode, monitor p95/p99 latency, consumed units, idle allocation and throttling reasons. Compare costs for the same successful workload and latency requirements. A cheaper configuration that drops peak requests is not an equivalent result.