Read/Write Capacity Mode:

When you provision Read Capacity Unit (RCU) and Write Capacity Unit (WCU) for Dynamo DB table, Always choose an option carefully after analysing the consumption as it may have a huge impact on the billing.

The read/write capacity mode controls how you are charged for read and write throughput and how you manage capacity. You can set the read/write capacity mode when creating a table or you can change it later.

Capacity modes for processing reads and writes in a DynamoDB table are:

• On-demand
• Provisioned (default, free-tier eligible)

On-Demand:

When you select On-Demand Capacity Mode while creating or re-configuring a table in DynamoDB, you only pay what we use as on-demand mode is bills you on pay-per-request model.

On-demand mode is preferable option when,

• You create new tables with unknown workloads. 
• You have unpredictable application traffic. 
• You prefer the ease of paying for only what you use. 

Note: You can switch between read/write capacity modes once every 24 hours.

Read Request Units and Write Request Units:

For on-demand mode tables, you don’t need to specify how much read and write throughput you expect your application to perform.  

DynamoDB charges you for the reads and writes that your application performs on your tables in terms of read request units and write request units. 

One read request unit represents one strongly consistent read request, or two eventually consistent read requests, for an item up to 4 KB in size.  Transactional read requests require 2 read request units to perform one read for items up to 4 KB. If you need to read an item that is larger than 4 KB, DynamoDB needs additional read request units. The total number of read request units required depends on the item size, and whether you want an eventually consistent or strongly consistent read. 

For example, if your item size is 8 KB, you require 2 read request units to sustain one strongly consistent read, 1 read request unit if you choose eventually consistent reads, or 4 read request units for a transactional read request. 

One write request unit represents one write for an item up to 1 KB in size. If you need to write an item that is larger than 1 KB, DynamoDB needs to consume additional write request units. Transactional write requests require 2 write request units to perform one write for items up to 1 KB. The total number of write request units required depends on the item size. For example, if your item size is 2 KB, you require 2 write request units to sustain one write request or 4 read request units for a transactional write request. 

Provisioned Mode:

In this mode, you specify the number of reads and writes per second that you require for your application. You can use auto scaling to adjust your table’s provisioned capacity automatically in response to traffic changes. This helps you govern your DynamoDB use to stay at or below a defined request rate in order to obtain cost predictability.

Provisioned mode is a good option if any of the following are true: 

• You have predictable application traffic. 
• You run applications whose traffic is consistent or ramps gradually. 
• You can forecast capacity requirements to control costs. 

When calling DescribeTable on an on-demand table, read capacity units and write capacity units are set to 0. 

If your application reads or writes larger items (up to the DynamoDB maximum item size of 400 KB), it will consume more capacity units. 

For example, suppose that you create a provisioned table with 6 read capacity units and 6 write capacity units. With these settings, your application could do the following: 

• Perform strongly consistent reads of up to 24 KB per second (4 KB × 6 read capacity units). 
• Perform eventually consistent reads of up to 48 KB per second (twice as much read throughput). 
• Perform transactional read requests of up to 3 KB per second. 
• Write up to 6 KB per second (1 KB × 6 write capacity units). 
• Perform transactional write requests of up to 3 KB per second. 

Note: Provisioned throughput is the maximum amount of capacity that an application can consume from a table or index. If your application exceeds your provisioned throughput capacity on a table or index, it is subject to request throttling.  Throttling prevents your application from consuming too many capacity units. When a request is throttled, it fails with an HTTP 400 code (Bad Request) and a ProvisionedThroughputExceededException.