AWS DynamoDB Throughput Capacity

• AWS DynamoDB throughput capacity depends on the read/write capacity modes for processing reads and writes on the tables.
• DynamoDB supports two types of read/write capacity modes:
  • Provisioned – maximum amount of capacity in terms of reads/writes per second that an application can consume from a table or index
  • On-demand (default and recommended) – serves thousands of requests per second without capacity planning.
• DynamoDB Auto Scaling helps dynamically adjust provisioned throughput capacity on your behalf, in response to actual traffic patterns.
• DynamoDB Burst capacity provides some flexibility in the per-partition throughput provisioning by providing burst capacity.
• DynamoDB Adaptive capacity is a feature that enables DynamoDB to run imbalanced workloads indefinitely. Adaptive capacity is instant.
• DynamoDB Warm Throughput (November 2024) provides visibility into table capacity and enables pre-warming for peak events.
• Configurable Maximum Throughput (May 2024) allows setting per-table maximum throughput limits for on-demand tables.

NOTE – DynamoDB throughput capacity, including both Provisioned and On-demand modes, is covered in the AWS Certified Developer – Associate exam (DVA-C02). RCU/WCU calculations, capacity mode selection, and throttling mitigation are key exam topics.

Pricing Reduction – November 2024

• Effective November 1, 2024, DynamoDB reduced prices significantly:
  • On-demand throughput: 50% price reduction
  • Global tables (on-demand): Up to 67% price reduction
  • Global tables (provisioned): 33% price reduction
• Makes DynamoDB more cost-effective for building, scaling, and optimizing applications.
• Applies to all AWS commercial Regions.
• On-demand mode is now the default and recommended throughput option for most DynamoDB workloads.

Provisioned Mode

• Provisioned mode requires you to specify the number of reads and writes per second as required by the application
• Provisioned throughput is the maximum amount of capacity that an application can consume from a table or index
• If the provisioned throughput capacity on a table or index is exceeded, it is subject to request throttling
• Provisioned mode provides the following capacity units
  • Read Capacity Units (RCU)
    • Total number of read capacity units required depends on the item size, and the consistent read model (eventually or strongly)
    • one RCU represents
      • two eventually consistent reads per second, for an item up to 4 KB in size i.e. 8 KB
      • one strongly consistent read per second for an item up to 4 KB in size i.e. 2x cost of eventually consistent reads
      • Transactional read requests require two read capacity units to perform one read per second for items up to 4 KB. i.e. 2x cost of strongly consistent reads
    • DynamoDB must consume additional read capacity units for items greater than 4 KB for e.g. for an 8 KB item size, 2 read capacity units to sustain one strongly consistent read per second, 1 read capacity unit if you choose eventually consistent reads, or 4 read capacity units for a transactional read request would be required
    • Item size is rounded off to 4 KB equivalents for e.g. a 6 KB or a 8 KB item in size would require the same RCU
  • Write Capacity Units (WCU)
    • Total number of write capacity units required depends on the item size only
    • one write per second for an item up to 1 KB in size
    • Transactional write requests require 2 write capacity units to perform one write per second for items up to 1 KB. i.e. 2x cost of general write.
    • DynamoDB must consume additional write capacity units for items greater than 1 KB for a 2 KB item size, 2 write capacity units would be required to sustain one write request per second or 4 write capacity units for a transactional write request
    • Item size is rounded off to 1 KB equivalents for e.g. a 0.5 KB or a 1 KB item would need the same WCU
• Provisioned capacity mode might be best for use cases where you
  • Have predictable application traffic
  • Run applications whose traffic is consistent or ramps gradually
  • Can forecast capacity requirements to control costs

Provisioned Mode Examples

• DynamoDB table with provisioned capacity of 10 RCUs and 10 WCUs can support
  • Read throughput
    • Eventual consistency = 4KB * 10 * 2 = 80KB/sec
    • Strong consistency = 4KB * 10 = 40KB/sec
    • Transactional consistency = 4KB * 10 * 1/2 = 20KB/sec
  • Write throughput
    • Eventual and Strong consistency = 10 * 1KB = 10KB/sec
    • Transaction consistency = 10 * 1KB * 1/2 = 5KB/sec
• Capacity units required for reading and writing 15KB item
  • Read capacity units – 15KB rounded to 4 blocks of 4KB = 4 RCUs
    • Eventual consistency 4 RCUs * 1/2 = 2 RCUs
    • Strong consistency 4 RCUs * 1 = 4 RCUs
    • Transactional consistency 4 RCUs * 2 = 8 RCUs
  • Write capacity units 15KB = 15 WCUs
    • Eventual and Strong consistency 15 WCUs * 1 = 15 WCUs
    • Transactional consistency 15 WCUs * 2 = 30 WCUs

On-demand Mode

• On-demand mode is the default and recommended throughput option for most DynamoDB workloads.
• On-demand mode provides a flexible billing option capable of serving thousands of requests per second without capacity planning.
• No need to specify the expected read and write throughput.
• Charged for only the reads and writes that the application performs on the tables in terms of read request units and write request units.
• Offers pay-per-request pricing for read and write requests so that you pay only for what you use.
• DynamoDB adapts rapidly to accommodate the changing load and can scale down to zero when no requests are being issued.
• DynamoDB on-demand uses Request units which are similar to provisioned capacity Units.
• On-demand mode does not support reserved capacity.
• Pricing reduced by 50% effective November 1, 2024.
• New on-demand tables can sustain up to 4,000 writes per second and 12,000 reads per second initially.
• On-demand throughput rate is bounded by a default 40,000 table-level read and write throughput service quota per account (can be increased via Service Quotas).
• On-demand capacity mode might be best for use cases where you
  • Create new tables with unknown workloads
  • Have unpredictable application traffic
  • Prefer the ease of paying for only what you use

Configurable Maximum Throughput for On-Demand Tables – May 2024

• Announced in May 2024, allows setting maximum read or write (or both) throughput for individual on-demand tables and associated GSIs.
• Provides an additional layer of cost predictability and manageability for on-demand tables.
• Throughput requests in excess of the configured maximum table throughput will be automatically throttled.
• The maximum throughput can be modified at any time based on application requirements.
• Key use cases:
  • Cost optimization – Bounds maximum spending per table while retaining on-demand flexibility.
  • Protection against accidental surges – Prevents runaway code from consuming excessive resources.
  • Safeguarding downstream services – Prevents overloading downstream services with fixed capacities.
• Previously, the on-demand request rate was only limited by the default 40,000 RRU/WRU account-level quota, which could not be customized per table.

DynamoDB Warm Throughput – November 2024

• Announced in November 2024, warm throughput provides visibility and control over table capacity.
• Warm throughput is the read and write capacity your DynamoDB table can instantly support based on historical usage.
• Available for both provisioned and on-demand tables and indexes at no cost.
• Provides insight into the operations your table or index can immediately support.
• Warm throughput values grow automatically as usage increases.
• Once increased, warm throughput values cannot be decreased.
• Available in all AWS commercial Regions (GovCloud added January 2025).

Pre-warming Tables

• You can pre-warm your table or index by proactively setting higher warm throughput values.
• Ideal for anticipated peak events like:
  • Product launches
  • Shopping events (Black Friday, Prime Day)
  • Marketing campaigns
  • Live streaming events
• Pre-warming ensures tables can handle 10x or 100x traffic surges instantly without throttling.
• DynamoDB automatically scales, but pre-warming eliminates the scaling delay.
• Pre-warming is an asynchronous operation; you can carry out other table updates while it completes.
• You can pre-warm up to the table or index quota limit for your account in that Region.
• There is no limit to the number of DynamoDB tables you can pre-warm at any time.
• Warm throughput values are available at no cost.
• Pre-warming incurs a charge (see DynamoDB pricing for details).

Capacity Mode Switching

• You can switch between on-demand and provisioned capacity modes.
• Provisioned to On-demand: Can be switched up to 4 times in a 24-hour rolling window (updated August 2025, previously limited to once per 24 hours).
• On-demand to Provisioned: Can be switched at any time with no frequency limitation.
• When switching from provisioned to on-demand:
  • DynamoDB ensures the table is scaled to sustain at least the previously provisioned or peak capacity.
  • New tables with provisioned below 4,000 WCU/12,000 RCU will be scaled to at least 4,000 writes/sec and 12,000 reads/sec.
  • Auto scaling settings are deleted (console) or preserved (CLI/SDK).
• When switching from on-demand to provisioned:
  • Table delivers throughput consistent with the previous peak reached during on-demand mode.
  • Use CloudWatch metrics (ConsumedWriteCapacityUnits, ConsumedReadCapacityUnits) to determine appropriate provisioned settings.
• You can bulk edit multiple tables to switch capacity modes in the DynamoDB console.

DynamoDB Throttling

• DynamoDB distributes the data across partitions and the provisioned throughput capacity is distributed equally across these partitions and these are physical partitions and not the logical partitions based on the primary key.
• Each partition on a DynamoDB table is subject to a hard limit of 1,000 write capacity units and 3,000 read capacity units.
• DynamoDB would throttle requests
  • If the workload is unevenly distributed across partitions, or if the workload relies on short periods of time with high usage (a burst of read or write activity), the table might be throttled.
  • When data access is imbalanced, a hot partition can receive a higher volume of read and write traffic compared to other partitions leading to throttling errors on that partition.
  • If the write throughput capacity on the GSI is not sufficient it would lead to throttling on a GSI and this would affect the base table.
  • If configurable maximum throughput is set on an on-demand table, requests exceeding that maximum will be throttled.
• To avoid and handle throttling issues, you can
  • Distribute read and write operations as evenly as possible across your table. A hot partition can degrade the overall performance of your table.
  • Use warm throughput and pre-warming for anticipated peak events to ensure instant capacity availability.
  • Implement a caching solution. If the workload is mostly read access to static data, then query results can be delivered much faster if the data is in a well‑designed cache rather than in a database. DynamoDB Accelerator (DAX) is a caching service that offers fast in‑memory performance for your application. ElastiCache can be used as well.
  • Implement error retries and exponential backoff. Exponential backoff can improve an application’s reliability by using progressively longer waits between retries. If using an AWS SDK, this logic is built‑in.
  • Switch to on-demand mode if workload is unpredictable to avoid provisioned throughput throttling entirely.

DynamoDB Burst Capacity

• DynamoDB provides some flexibility in the per-partition throughput provisioning by providing burst capacity.
• If partition’s throughput is not fully used, DynamoDB reserves a portion of that unused capacity for later bursts of throughput to handle usage spikes.
• DynamoDB currently retains up to 5 minutes (300 seconds) of unused read and write capacity.
• During an occasional burst of read or write activity, these extra capacity units can be consumed quickly – even faster than the per-second provisioned throughput capacity that you’ve defined for your table.
• DynamoDB can also consume burst capacity for background maintenance and other tasks without prior notice.
• Burst capacity details may change in the future.

DynamoDB Adaptive Capacity

• DynamoDB Adaptive capacity is a feature that enables DynamoDB to run imbalanced workloads indefinitely.
• Adaptive capacity is instant — it responds immediately to traffic imbalances by increasing throughput capacity for partitions that receive more traffic.
• Adaptive capacity enables the application to continue read/write to hot partitions without being throttled, provided that traffic does not exceed the table’s total provisioned capacity or the partition’s maximum capacity.
• It minimizes throttling due to throughput exceptions.
• It also helps reduce costs by enabling the provisioning of only the needed throughput capacity.
• Adaptive capacity is enabled automatically for every DynamoDB table, at no additional cost. You don’t need to explicitly enable or disable it.
• Isolating Frequently Accessed Items:
  • Adaptive capacity rebalances partitions so that frequently accessed items don’t reside on the same partition.
  • If a single item drives consistently high traffic, adaptive capacity may isolate it on its own partition.
  • A single item can receive throughput up to the partition maximum of 3,000 RCUs and 1,000 WCUs.

Capacity Mode Comparison

Feature	Provisioned Mode	On-Demand Mode
Capacity Planning	Required (specify RCU/WCU)	Not required (automatic)
Pricing Model	Pay for provisioned capacity (hourly)	Pay per request (50% reduced Nov 2024)
Best For	Predictable, steady traffic	Unpredictable/spiky traffic (default)
Auto Scaling	Supported (Application Auto Scaling)	Automatic (built-in, scales to zero)
Warm Throughput	Supported	Supported
Configurable Max Throughput	N/A (set explicit capacity)	Supported (May 2024)
Reserved Capacity	Supported	Not supported
Initial Capacity (new tables)	As specified	4,000 WPS / 12,000 RPS
Account-level Default Quota	N/A	40,000 RRU/WRU per table (adjustable)
Switch to Other Mode	Up to 4 times per 24hrs to on-demand	Any time to provisioned

AWS Certification Exam Practice Questions

• Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
• AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
• AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
• Open to further feedback, discussion and correction.

1. You need to migrate 10 million records in one hour into DynamoDB. All records are 1.5KB in size. The data is evenly distributed across the partition key. How many write capacity units should you provision during this batch load?
   1. 6667
   2. 4166
   3. 5556 ( 2 write units (1 for each 1KB) * 10 million/3600 secs)
   4. 2778
2. A meteorological system monitors 600 temperature gauges, obtaining temperature samples every minute and saving each sample to a DynamoDB table. Each sample involves writing 1K of data and the writes are evenly distributed over time. How much write throughput is required for the target table?
   1. 1 write capacity unit
   2. 10 write capacity units ( 1 write unit for 1K * 600 gauges/60 secs)
   3. 60 write capacity units
   4. 600 write capacity units
   5. 3600 write capacity units
3. A company is building a system to collect sensor data from its 36000 trucks, which is stored in DynamoDB. The trucks emit 1KB of data once every hour. How much write throughput is required for the target table. Choose an answer from the options below
   1. 10
   2. 60
   3. 600
   4. 150
4. A company is using DynamoDB to design storage for their IOT project to store sensor data. Which combination would give the highest throughput?
   1. 5 Eventual Consistent reads capacity with Item Size of 4KB (40KB/s)
   2. 15 Eventual Consistent reads capacity with Item Size of 1KB (30KB/s)
   3. 5 Strongly Consistent reads capacity with Item Size of 4KB (20KB/s)
   4. 15 Strongly Consistent reads capacity with Item Size of 1KB (15KB/s)
5. If your table item’s size is 3KB and you want to have 90 strongly consistent reads per second, how many read capacity units will you need to provision on the table? Choose the correct answer from the options below
   1. 90
   2. 45
   3. 10
   4. 19
6. A company is planning a major product launch that will generate 10x normal traffic for 2 hours. What feature should they use to ensure DynamoDB can handle the spike instantly?
   1. DynamoDB Auto Scaling
   2. Burst capacity
   3. Warm throughput with pre-warming
   4. Adaptive capacity
7. When should you start pre-warming a DynamoDB table for an anticipated peak event?
   1. 1 hour before the event
   2. 6 hours before the event
   3. At least 24 hours before the event (pre-warming is asynchronous and completion time depends on the values set)
   4. 1 week before the event
8. Which of the following statements about DynamoDB capacity modes are correct? (Select THREE)
   1. On-demand pricing was reduced by 50% in November 2024
   2. Provisioned mode does not support warm throughput
   3. New on-demand tables can sustain 4,000 writes and 12,000 reads per second initially
   4. On-demand mode supports reserved capacity
   5. Warm throughput values are available at no cost, but pre-warming incurs charges
9. A development team wants to prevent a runaway application from generating excessive DynamoDB costs on their on-demand table. Which feature should they configure?
   1. DynamoDB Auto Scaling with max capacity
   2. Provisioned capacity with burst limits
   3. Configurable maximum throughput for on-demand tables
   4. Reserved capacity with cost alerts
10. How many times can you switch a DynamoDB table from provisioned capacity mode to on-demand mode within a 24-hour period?
    1. Once
    2. Twice
    3. Four times
    4. Unlimited

References

• DynamoDB Developer Guide
• DynamoDB Throughput Capacity
• Understanding DynamoDB Warm Throughput
• DynamoDB Maximum Throughput for On-Demand Tables
• Considerations When Switching Capacity Modes
• DynamoDB Burst and Adaptive Capacity
• Pre-warming Amazon DynamoDB Tables with Warm Throughput
• Amazon DynamoDB Lowers Pricing for On-Demand Throughput and Global Tables
• Introducing Configurable Maximum Throughput for DynamoDB On-Demand
• DynamoDB More Frequent Throughput Mode Updates (August 2025)