DynamoDB capacity modes: on-demand and provisioned

Read capacity units (RCUs)

What is a DynamoDB RCU?

One read capacity unit supports one strongly consistent read per second of an item up to 4 KB, or two eventually consistent reads of that item per second. A transactional read needs two read units per 4 KB. DynamoDB uses 1,024 bytes per KB.

For a single-item read, round the item's size up to the next 4 KB, then apply the consistency multiplier: 1 for strong, 0.5 for eventual, or 2 for transactional. Multiply by reads per second to estimate provisioned RCUs. For example, 100 reads per second of a 6 KB item need 200 RCUs strongly consistent, 100 eventually consistent, or 400 transactional.

On-demand uses the same size and consistency calculation, but bills read request units (RRUs) for requests made rather than provisioned capacity per hour. An RRU is a quantity consumed, not a per-second reservation.

Which bytes count for a read?

GetItem uses the full item size even if you request only some attributes. BatchGetItem rounds each item separately. Query and Scan add the sizes of items evaluated for each request before rounding; a filter discards results after this work and does not reduce read consumption. Empty reads still have a minimum charge.

Strong reads are available on tables and local secondary indexes, but global secondary indexes support eventually consistent reads only. Measure real requests with ReturnConsumedCapacity and use the item size calculator for individual items.

Write capacity units (WCUs)

What is a DynamoDB WCU?

One write capacity unit supports one nontransactional write per second of an item up to 1 KB. Round each item's size up to the next 1 KB; transactional writes use twice that number. A 1.5 KB item therefore needs 2 write units normally or 4 in a transaction.

For 100 writes per second of that item, provision at least 200 WCUs before allowing for traffic variation and index writes. On-demand bills 2 write request units (WRUs) per ordinary write instead. Writes do not have an eventual-consistency discount; the consistency choice applies to reads.

UpdateItem uses the larger of the item's size before and after the update, even if you change only one attribute. Replacing an existing item with PutItem also uses the larger size. DeleteItem uses the old item size, with a minimum write charge even if no item exists. BatchWriteItem rounds each put or delete separately.

Index maintenance can consume additional write capacity. Each global secondary index has separate provisioned capacity, and an underprovisioned index can throttle writes to the base table. Estimate the projected index item separately instead of assuming that one base-table write always costs one unit.

DynamoDB provisioned capacity and auto scaling

Provisioned mode lets you choose read and write capacity per second for the table and each global secondary index. You pay for that capacity by the hour, including capacity you do not consume. It can cost less for predictable workloads with sustained utilization.

In US East (N. Virginia), Standard tables cost $0.00065 per WCU-hour and $0.00013 per RCU-hour before allowances or discounts. At full utilization, that is about $0.18 per million writes of up to 1 KB, compared with $0.625 on-demand. The approximate break-even is 29% utilization at those rates, excluding free tier, discounts, scaling headroom and operational work.

How does DynamoDB auto scaling work?

Application Auto Scaling changes provisioned capacity within configured minimum and maximum values to track a utilization target. Configure read and write scaling for the table and its GSIs. A GSI's capacity is independent of the table, so a table scaling policy alone does not protect index writes.

Scaling is reactive, not instant. AWS documents scale-up after two consecutive minutes above the target, followed by CloudWatch alarm evaluation and a capacity update that can take several minutes. Short spikes can throttle before scaling catches up. Schedule capacity increases ahead of known peaks, or use on-demand for unpredictable traffic.

Provisioned capacity starts at 1 RCU and 1 WCU per table or GSI. Account and table quotas still apply when auto scaling is enabled. Watch consumed capacity, throttled requests and the configured maximum rather than assuming a scaling policy can grow without a limit.

See AWS auto scaling behavior and the pricing calculator to compare your workload in both modes.

Reserved capacity and Database Savings Plans

Reserved capacity is a billing discount for committed provisioned usage, not a third capacity mode. You purchase blocks of 100 RCUs or 100 WCUs for a one-year or three-year term. It applies to single-Region Standard-class provisioned capacity, including GSIs, but not Standard-IA, on-demand requests or replicated write capacity.

AWS advertises savings of up to 54% for one year and 77% for three years compared with ordinary provisioned pricing. Three-year reservations are available only in selected Regions. Include both the upfront payment and recurring hourly charge when comparing costs; unused reserved units still cost money, and reservations cannot be canceled or moved to another Region.

Database Savings Plans offer a different commitment: a consistent hourly spend for one year, with flexibility across eligible AWS database services and Regions. DynamoDB discounts are up to 18% on on-demand throughput and up to 12% on provisioned throughput. Reserved capacity applies first, and the same usage does not receive both discounts.

Choose a commitment only after measuring your baseline. Keep variable demand outside the reservation, and check eligible usage and current Region prices on the AWS DynamoDB pricing page. Neither discount removes storage, backup or other separately billed charges.

DynamoDB adaptive capacity

Adaptive capacity automatically shifts throughput toward partitions receiving more traffic. It is enabled for every table at no extra charge and applies to both on-demand and provisioned modes. It helps uneven access patterns, but does not remove table or partition limits.

A physical partition supports up to 3,000 read units and 1,000 write units per second. These are units, not arbitrary-size requests: a strongly consistent read of a 20 KB item uses 5 units, so one hot item reaches the read limit at about 600 such reads per second. Provisioned traffic must also fit within the table's total capacity.

DynamoDB can isolate hot items or split partitions to redistribute load. A single hot item's writes still cannot exceed a partition's write limit. Tables with local secondary indexes cannot split an item collection across partitions, so key design remains important.

If throttling persists, inspect ThrottlingReasons and Contributor Insights to locate hot keys. Spread writes across suitable keys, cache repeated reads where appropriate, and check GSI key distribution too. AWS describes adaptive and burst capacity as complementary mechanisms.

DynamoDB burst capacity

DynamoDB retains up to five minutes (300 seconds) of unused read and write capacity for occasional bursts. It can consume this reserve faster than the provisioned per-second rate, allowing some requests above that rate to succeed.

Burst capacity is not a guaranteed extra five minutes of peak traffic. The available reserve depends on earlier usage, and DynamoDB can spend it on background maintenance without notice. Once it runs out, requests above the available throughput can throttle. Do not size a sustained workload around burst capacity.

Burst capacity absorbs short spikes; adaptive capacity addresses uneven traffic across partitions; auto scaling changes provisioned capacity over time. None substitutes for a suitable partition key or enough capacity for a sustained peak.

DynamoDB on-demand capacity

On-demand is AWS's default and recommended capacity mode for most workloads. You pay for read and write request units consumed without reserving throughput, so it suits new applications, variable demand and idle periods. Both billing modes are fully managed.

AWS cut on-demand throughput prices by 50% effective November 1, 2024. Standard-class rates in US East (N. Virginia) are $0.625 per million WRUs and $0.125 per million RRUs. There is no free on-demand request allowance; the Standard storage allowance is separate.

How quickly does on-demand scale?

A new table starts with capacity for 12,000 read units and 4,000 write units per second. On-demand immediately accommodates up to twice the previous peak. Traffic exceeding twice that peak within 30 minutes can throttle, so ramp gradually or pre-warm ahead of an unusually large launch.

Warm throughput versus maximum throughput

Warm throughput reports the reads and writes per second a table or GSI can support immediately. It is visible in both capacity modes. DynamoDB increases it as usage grows; you can also request a paid increase before a planned peak. Pre-warming does not switch billing modes or remove provisioned-capacity, quota or hot-partition limits.

Maximum throughput is an optional on-demand read or write cap for a table or GSI. Requests above it can be throttled to control consumption. It is a best-effort target, not a guaranteed spending ceiling, because burst capacity can temporarily exceed it. Storage and other charges are outside this cap.

The default table or individual GSI throughput quota is 40,000 read units and 40,000 write units per second, adjustable through Service Quotas. Check your actual quotas and any configured maximum before pre-warming.

How often can you change capacity modes?

You can switch from provisioned to on-demand up to four times in a rolling 24-hour period. You can switch from on-demand to provisioned at any time. Review table and GSI capacity when switching back, and wait for the update to finish before relying on the new settings.

See AWS's on-demand scaling rules, warm throughput guide and maximum throughput behavior.