Choose DynamoDB capacity without paying for idle throughput

Why this is worth a look

Skipping this review can make a steady workload pay for unused provisioned capacity or make a bursty workload throttle while auto scaling catches up. Provisioned billing is based on allocated capacity, while on-demand billing is per consumed read or write request. Target utilization trades lower cost for higher throttling risk.

Use CloudWatch and a DynamoDB settings report to compare one table and its indexes over a representative period. The checklist makes no capacity changes.

Scope and inputs
[ ] Record the AWS account, Region, table name and review dates. Start with 14 days and include known peaks.
[ ] Obtain read-only settings and CloudWatch results from an authorized AWS colleague if needed.
[ ] Record the table capacity mode and every global secondary index (GSI).
[ ] For provisioned capacity, record table and GSI read/write capacity, plus configured auto scaling minimum, maximum and target utilization.
[ ] For on-demand capacity, record maximum read/write throughput settings for the table and each GSI.

Metrics and units
[ ] Use TableName for table metrics. For each GSI, use both TableName and GlobalSecondaryIndexName. Table-only capacity metrics exclude GSIs.
[ ] Retrieve ConsumedReadCapacityUnits and ConsumedWriteCapacityUnits with Sum over each one-minute period. These sums are counts, not units per second.
[ ] Divide each one-minute consumed Sum by 60 before comparing it with provisioned throughput. Keep reads and writes separate.
[ ] For provisioned mode, review ProvisionedReadCapacityUnits and ProvisionedWriteCapacityUnits over the same dates for the table and each GSI.
[ ] Review ReadThrottleEvents and WriteThrottleEvents for the table and each GSI. Flag periods where provisioned capacity was exceeded.

Cost and decision
[ ] Record operation types, item sizes, read consistency and transactional usage. One application request is not necessarily one capacity unit.
[ ] Use consumed unit totals for the on-demand comparison, not per-second averages. Compare against capacity provisioned over the same period, accounting for capacity changes.
[ ] Ask the cost owner to apply applicable rates to both options and include eligible reserved capacity discounts for provisioned mode.
[ ] Prefer on-demand for fluctuating traffic. Consider provisioned for steady demand only when the priced comparison supports it without increasing throttling.
[ ] Record the recommendation and unresolved assumptions. Do not switch modes during this review.

How to confirm it

1. 01

   Choose a representative period

   Record one account, Region, table and its global secondary indexes (GSIs). Start with 14 days of metrics and include known peaks before deciding. Request the checklist's settings and metric results from the table owner if you lack access.

2. 02

   Compare like-for-like throughput

   Divide each one-minute consumed Sum by 60 before comparing it with provisioned throughput. Review reads and writes separately for the table and each GSI. A TableName-only view excludes index capacity.

3. 03

   Check burst and scaling risk

   Compare idle provisioned capacity with throttling periods. Review auto scaling minimum, maximum and target utilization: a lower target increases cost and reduces throttling risk, while a higher target reduces overprovisioning and increases throttling risk. Record on-demand maximum throughput settings because they bound usage.

4. 04

   Price both modes consistently

   Ask the cost owner to compare consumed request units with capacity provisioned over the same period, using applicable rates and eligible reserved capacity discounts. Record operation types, item sizes, read consistency and transactions because reads round to 4 KB and writes to 1 KB.

5. 05

   Check switching limits

   Confirm the recommendation with the workload owner before changing mode. Provisioned-to-on-demand switches are limited to four in a rolling 24-hour window, while on-demand-to-provisioned switches can occur at any time. Do not approve provisioned capacity solely because average use looks steady.

Primary sources