Quotas in Amazon DynamoDB
This section describes current quotas, formerly referred to as limits, within Amazon DynamoDB. Each quota applies on a per-Region basis unless otherwise specified.
Topics
Read/write throughput
Throughput default quotas
AWS places some default quotas on the throughput that your account can provision and consume within a Region.
The account-level read throughput and account-level write throughput quotas apply at the account level. These account-level quotas apply to the sum of the provisioned throughput capacity for all your account’s tables and global secondary indexes in a given Region. All the account's available throughput can be provisioned for a single table or across multiple tables. These quotas only apply to tables using the provisioned capacity mode.
The table-level read throughput and table-level write throughput quotas apply differently to tables that use the provisioned capacity mode, and tables that use the on-demand capacity mode.
For provisioned capacity mode tables and GSIs, the quota is the maximum amount of read and write capacity units that can be provisioned for any table or any of its GSIs in the Region. The total of any individual table and all its GSIs must also remain below the account-level read and write throughput quota. This is in addition to the requirement that the total of all provisioned tables and their GSIs must remain below the account-level read and write throughput quota.
For on-demand capacity mode tables and GSIs, the table-level quota is the maximum read and write capacity units that are available for any table, or any individual GSI within that table. No account-level read and write throughput quotas are applied to tables in on-demand mode.
Following are the throughput quotas that apply on your account, by default.
Throughput quota name | On-Demand | Provisioned | Adjustable |
---|---|---|---|
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
Increasing or decreasing throughput (for provisioned tables)
Increasing provisioned throughput
You can increase ReadCapacityUnits
or
WriteCapacityUnits
as often as necessary, using the AWS Management Console
or the UpdateTable
operation. In a single call, you can increase
the provisioned throughput for a table, for any global secondary indexes on that
table, or for any combination of these. The new settings do not take effect
until the UpdateTable
operation is complete.
You can't exceed your per-account quotas when you add provisioned capacity, and DynamoDB doesn't allow you to increase provisioned capacity very rapidly. Aside from these restrictions, you can increase the provisioned capacity for your tables as high as you need. For more information about per-account quotas, see the preceding section, Throughput default quotas.
Decreasing provisioned throughput
For every table and global secondary index in an
UpdateTable
operation, you can decrease
ReadCapacityUnits
or WriteCapacityUnits
(or both).
The new settings don't take effect until the UpdateTable
operation
is complete.
There is a default quota on the number of provisioned capacity decreases you can perform on your DynamoDB table per day. A day is defined according to Universal Time Coordinated (UTC). On a given day, you can start by performing up to four decreases within one hour as long as you have not performed any other decreases yet during that day. Subsequently, you can perform one additional decrease per hour (once every 60 minutes). This effectively brings the maximum number of decreases in a day to 27 times.
Important
Table and global secondary index decrease limits are decoupled, so any global secondary indexes for a particular table have their own decrease limits. However, if a single request decreases the throughput for a table and a global secondary index, it is rejected if either exceeds the current limits. Requests are not partially processed.
Example
In the first 4 hours of a day, a table with a global secondary index can be modified as follows:
-
Decrease the table's
WriteCapacityUnits
orReadCapacityUnits
(or both) four times. -
Decrease the
WriteCapacityUnits
orReadCapacityUnits
(or both) of the global secondary index four times.
At the end of that same day, the table and the global secondary index throughput can potentially be decreased a total of 27 times each.
Reserved Capacity
AWS places a default quota on the amount of active reserved capacity that your account can purchase. The quota limit is a combination of reserved capacity for write capacity units (WCUs) and read capacity units (RCUs).
Reserved capacity quota | Active reserved capacity | Adjustable |
---|---|---|
Per account |
1,000,000 provisioned capacity units (WCUs _ RCUs) |
Yes |
If you attempt to purchase more than 1,000,000 provisioned capacity units in a single purchase, you will receive an error for this service quota limit. If you have active reserved capacity and attempt to purchase additional reserved capacity that would result in more than 1,000,000 active provisioned capacity units, you will receive an error for this service quota limit.
Tables
Table size
There is no practical limit on a table's size. Tables are unconstrained in terms of the number of items or the number of bytes.
Maximum number of tables per account per region
For any AWS account, there is an initial quota of 2,500 tables per AWS Region.
If you need more than 2,500 tables for a single account, please reach out to your AWS account team to explore an increase up to a maximum of 10,000 tables. For more than 10,000, the recommended best practice is to setup multiple accounts, each of which can serve up to 10,000 tables.
Transactions for global tables
The following default quotas apply when using global tables.
Default global table quotas | On-Demand | Provisioned |
---|---|---|
Throughput per table |
|
|
Backfilled data for new replicas per account, per Region, per day |
|
|
Transactional operations provide atomicity, consistency, isolation, and durability
(ACID) guarantees only within the AWS Region where the write API was invoked.
Transactions aren't supported across Regions in global tables. For example, suppose that
you have a global table with replicas in the US East (Ohio) and US West (Oregon) Regions
and you perform a TransactWriteItems
operation in the US East (N. Virginia)
Region, you may observe partially completed transactions in the US West (Oregon) Region
as changes are replicated. Changes are replicated to other Regions only after they've
been committed in the source Region.
Note
There may be instances where you will need to request a quota limit increase
through AWS Support. If any of the following apply to you, please see https://aws.amazon.com/support
-
If you are adding a replica for a table that is configured to use more than 40,000 write capacity units (WCU), you must request a service quota increase for your add replica WCU quota.
-
If you are adding a replica or replicas to one destination Region within a 24-hour period with a combined total greater than 10TB, you must request a service quota increase for your add replica data backfill quota.
-
If you encounter an error similar to the following:
-
Cannot create a replica of table 'example_table' in region 'example_region_A' because its exceeds your current account limit in region 'example_region_B'.
-
Secondary indexes
You can define up to 5 local secondary indexes per table.
There is a default quota of 20 global secondary indexes per table.
Projected secondary index attributes
You can project up to 100 attributes combined for all of a table's local and global secondary indexes. This quota only applies to user-specified projected attributes.
For the CreateTable
operation, if you specify a
ProjectionType
of INCLUDE
, the total count of attributes
specified in NonKeyAttributes
summed across all secondary indexes must not
exceed 100. Projecting the same attribute name into two different indexes counts as two
distinct attributes toward the quota.
This quota doesn't apply to secondary indexes with a ProjectionType
of
KEYS_ONLY
or ALL
.
DynamoDB Streams
Simultaneous readers of a shard in DynamoDB Streams
For single-Region tables that are not global tables, you can design for up to two simultaneous processes to read from the same DynamoDB Streams shard at the same time. Exceeding this limit can result in request throttling. For global tables, we recommend you limit the number of simultaneous readers to one to avoid request throttling.
Maximum write capacity for a table with DynamoDB Streams enabled
AWS places some default quotas on the write capacity for DynamoDB tables with DynamoDB Streams enabled. These default quotas are applicable only for tables in provisioned read/write capacity mode. amount.
-
US East (N. Virginia), US East (Ohio), US West (N. California), US West (Oregon), South America (São Paulo), Europe (Frankfurt), Europe (Ireland), Asia Pacific (Tokyo), Asia Pacific (Seoul), Asia Pacific (Singapore), Asia Pacific (Sydney), China (Beijing) Regions:
-
Per table – 40,000 write capacity units
-
-
All other Regions:
-
Per table – 10,000 write capacity units
-
Import from Amazon S3
DynamoDB Import from Amazon S3 can support up to 50 concurrent import jobs with a total import source object size of 15TB at a time in us-east-1, us-west-2, and eu-west-1 regions. In all other regions, up to 50 concurrent import tasks with a total size of 1TB is supported. Each import job can take up to 50,000 Amazon S3 objects in all regions. For more information on import and validation, see import format quotas and validation.
Table export to Amazon S3
Full export: up to 300 concurrent export tasks, or up to a total of 100TB from all in-flight table exports, can be exported. Both of these limits are checked before an export is queued.
Incremental export: DynamoDB Incremental Export to Amazon S3 can support up to 300 concurrent export jobs or up to a total of 100TB from all in-flight table exports. The export period window limits are 15 minutes minimum and 24 hours maximum.
Backup and restore
DynamoDB supports up to 50 concurrent restores totaling 50 TB via DynamoDB on-demand or continuous backups. AWS Backup supports up to 50 concurrent restores totaling 25 TB.
Contributor Insights
When you enable Customer Insights on your DynamoDB table, you're still subject to Contributor Insights rules limits. For more information, see CloudWatch service quotas.