DynamoDB: Provisioned vs on demand capacity
When it comes to setting up DynamoDB most of the heavy lifting is done by DynamoDB and one of the most important and I would say only decision needs to be made is around capacity settings
On-demand
Application owners don’t have to explicitly configure read/write capacity and DynamoDB takes care of autoscaling based on load. For on demand capacity works on pay for, what you use.
On-demand mode is a good option if any of the following are true:
- You create new tables with unknown workloads.
- You have unpredictable application traffic.
- You prefer the ease of paying for only what you use.
DynamoDB keeps adjusting available RCUs and WCUs as load from the application side increases and decreases after it. Even if load doubles from 5,000 RCUs to 10,000 DynamoDB will adjust the capacity instantly to meet the demand to make sure workload does not experiences throttling. If load increases more than double within 30 mins it will throw throttling exceptions.
If current load is for 5,000 RCUs and keep varying between 5,000 to 10, 000 RCUs for 30 mins dynamo will keep adjusting capacity. If increases beyond it, application will experience throttle exceptions for sometime. DynamoDB advocates pacing out load increase over a period of time rather than sudden burst.
Below is an example of pricing model for on-demand.
Provisioned
If you choose provisioned 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.
In provisioned capacity account level read and write quotas get shared across all tables and GSIs in the account for all regions.
For provisioned capacity when certain partitions are hot partitions and have burst traffic situation Dynamo adjusts capacity which is called adaptive capacity. I have covered adaptive capacity in details at: https://medium.com/@deeptimittalblogger/dynamodb-data-partitioning-is-the-secret-sauce-c810eb9f80ca
Below is an example of pricing model for provisioned capacity which is different than on-demand.
Reserved capacity
Provisioned capacity has another option for pricing which is reserved capacity. DynamoDB gives you an option to reserve the capacity for 1 year team or 3 year term by paying some upfront cost and after that paying hourly cost for unit purchased. This option is used to stable traffic over the year/s to get huge discount and cost saving on dynamoDB. Reserved capacity can save you up to 77% over standard provisioned capacity rates.
Below is pricing model for reserved capacity.
One-year reserved capacity is available in all Regions, and three-year is available in limited Regions. This is just a billing feature and does not have any impact on dynamoDB performance.
Account level quota limitation for provisioned and on-demand
In provisioned capacity account level read and write quotas get shared across all tables and GSIs in the account for all regions.
For on-demand on account level quotas are applied and every table will have its on RCUs and WCUs to be shared across partitions. If a table has GSIs defined they will share the quota from main table.
You can read more about GSIs and indexes on dynamoDB from my previous blog at: https://medium.com/@deeptimittalblogger/dynamodb-how-different-indexes-are-here-9b394c1ba4f8
By default below are the throughput quotas that apply to any account which can be adjusted by calling AWS support.
Switching from Provisioned to On-demand
When you switch a table from provisioned capacity mode to on-demand capacity mode, DynamoDB makes several changes to the structure of your table and partitions. This process can take several minutes. During the switching period, your table delivers throughput that is consistent with the previously provisioned write capacity unit and read capacity unit amounts.
When you update a table from provisioned to on-demand mode, you don’t need to specify how much read and write throughput you expect your application to perform.
If you recently switched an existing table to on-demand capacity mode for the first time, or if you created a new table with on-demand capacity mode enabled, the table will consider previous peak settings, even though the table has not served traffic previously using on-demand capacity mode.
Following are examples of possible scenarios.
- A provisioned table configured as 100 WCU and 100 RCU. When this table is switched to on-demand for the first time, DynamoDB will ensure it is scaled out to instantly sustain at least 4,000 write units/sec and 12,000 read units/sec.
- A provisioned table configured as 8,000 WCU and 24,000 RCU. When this table is switched to on-demand, it will continue to be able to sustain at least 8,000 write units/sec and 24,000 read units/sec at any time.
- A provisioned table configured with 8,000 WCU and 24,000 RCU, that consumed 6,000 write units/sec and 18,000 read units/sec for a sustained period. When this table is switched to on-demand, it will continue to be able to sustain at least 8,000 write units/sec and 24,000 read units/sec. The previous traffic may further allow the table to sustain much higher levels of traffic without throttling.
- A table previously provisioned with 10,000 WCU and 10,000 RCU, but currently provisioned with 10 RCU and 10 WCU. When this table is switched to on-demand, it will be able to sustain at least 10,000 write units/sec and 10,000 read units/sec.
Tables can be switched to on-demand mode once every 24 hours.
Switching from on demand to Provisioned mode
When switching from on-demand capacity mode back to provisioned capacity mode, your table delivers throughput consistent with the previous peak reached when the table was set to on-demand capacity mode.
If you are switching from on-demand mode back to provisioned mode, make sure to set the initial provisioned units high enough to handle your table or index capacity during the transition.
Tables can be returned to provisioned capacity mode at any time.
For issues to consider when switching read/write capacity modes, see Considerations when changing read/write Capacity Mode.
We have created a series of dynamoDB blogs and do check them out to understand more concepts on DynamoDB:
dynamodb-all-you-need-to-know-about-it
data-partitioning-is-the-secret-sauce
how-different-indexes-are-here
demystifying-dynamodb-partition-keys
unlocking-efficient-data-retrieval-in-dynamodb
