DynamoDB 的容量边界分为两个层级：单表可以配置多少预置容量，以及整个账户在当前区域可以配置多少预置容量。很多项目在扩容时只关注单表上限，却忽略了账户级总量，导致新建表或提升某张表容量时被直接拒绝。DescribeLimits 接口就是用来查询这些边界的入口，它不需要任何请求参数，只返回四个与容量单元有关的数值。理解这四个字段的含义、单位以及它们和实际流量的关系，是做好 DynamoDB 容量规划的第一步。
这四个数值并不代表你已经使用了多少容量，也不代表当前表正在消耗多少容量。它们描述的是账户和单表能够配置的预置读/写容量上限。比如账户级读上限是 80000，意味着该区域所有预置表加起来最多可以配置 80000 个读容量单元。如果已经用掉了 75000，再新建一张需要 10000 读容量的表时，请求就会失败。单表上限则更直接，任何一张表的 ProvisionedThroughput 都不能超过 TableMaxReadCapacityUnits 和 TableMaxWriteCapacityUnits 指定的数值。
一、DescribeLimits 返回的四个核心字段
调用 DescribeLimits 时不需要指定表名，也不需要传入任何参数。它的响应结构非常简洁，只有四个整数类型的字段，分别是 AccountMaxReadCapacityUnits、AccountMaxWriteCapacityUnits、TableMaxReadCapacityUnits 和 TableMaxWriteCapacityUnits。前两个字段负责描述账户级限制，后两个字段负责描述单表限制。单位全部是 DynamoDB 的容量单元，读容量单元简称 RCU，写容量单元简称 WCU。
以 AWS CLI 为例，查询当前区域限制的命令如下：
aws dynamodb describe-limits --region ap-southeast-1
返回结果可能类似这样：
{
"AccountMaxReadCapacityUnits": 80000,
"AccountMaxWriteCapacityUnits": 80000,
"TableMaxReadCapacityUnits": 40000,
"TableMaxWriteCapacityUnits": 40000
}
从上面的响应可以看出，该账户在 ap-southeast-1 区域最多可以配置 80000 个读容量单元和 80000 个写容量单元，而每一张表最多只能配置 40000 个读容量单元和 40000 个写容量单元。需要注意的是，这个接口返回的是预置容量模式的限制。如果你的表使用按需模式，它不直接体现按需流量的账户上限，这一点后面会详细展开。
另外，DescribeLimits 并不会返回表数量限制。DynamoDB 默认每个账户每个区域最多可以创建 2500 张表，这个限制需要通过 Service Quotas 控制台、ListTables 分页统计或提交支持工单来确认和提升。很多开发者第一次看到 DescribeLimits 的名字，会误以为它能展示全部账户限制，但实际上它只聚焦于预置吞吐容量。
二、如何计算当前账户的预置使用率
知道了上限以后，下一步是计算当前账户已经配置了多少预置容量。这个过程不能直接通过某一个接口完成，需要遍历账户下所有预置表，将每张表的 ReadCapacityUnits 和 WriteCapacityUnits 累加起来。表数量较多时可以使用分页器，避免一次拉取超时。
下面这段 Python 代码会先调用 DescribeLimits 获取账户上限，然后遍历所有表并统计当前预置容量总和，最后计算使用率：
import boto3
dynamodb = boto3.client('dynamodb', region_name='ap-southeast-1')
limits = dynamodb.describe_limits()
account_max_read = limits['AccountMaxReadCapacityUnits']
account_max_write = limits['AccountMaxWriteCapacityUnits']
total_read = 0
total_write = 0
paginator = dynamodb.get_paginator('list_tables')
for page in paginator.paginate():
for table_name in page['TableNames']:
desc = dynamodb.describe_table(TableName=table_name)
tp = desc['Table'].get('ProvisionedThroughput', {})
total_read += tp.get('ReadCapacityUnits', 0)
total_write += tp.get('WriteCapacityUnits', 0)
print('账户读上限:', account_max_read, '当前预置读:', total_read)
print('账户写上限:', account_max_write, '当前预置写:', total_write)
if account_max_read > 0 and total_read / account_max_read > 0.8:
print('读容量使用率超过80%，建议评估提升')
if account_max_write > 0 and total_write / account_max_write > 0.8:
print('写容量使用率超过80%，建议评估提升')
这段脚本只统计了预置模式表的容量，按需模式表不会出现在 ProvisionedThroughput 中，因此不会影响统计结果。如果账户下既有预置表又有按需表，需要分别管理两类容量边界。预置表占用的容量越接近账户上限，可用来新建预置表的空间就越小。
除了自己写脚本，也可以借助 CloudWatch 观察实际消耗。DynamoDB 会为每张表发布 ConsumedReadCapacityUnits 和 ConsumedWriteCapacityUnits 指标，单位为容量单元，统计周期内实际消耗的平均值。把实际消耗与预置容量进行对比，可以判断是否存在持续限流风险。一般建议实际消耗不要长时间超过预置容量的 70%，因为 DynamoDB 虽然在短时间内允许突发，但持续超过预置容量后会触发节流，请求会返回 ProvisionedThroughputExceededException。
三、预置模式与按需模式的限制差异
DynamoDB 提供两种容量模式：预置容量和按需容量。预置容量模式下，你需要明确指定每张表的 RCU 和 WCU，费用相对可预测，但需要主动管理扩容。按需模式下，表不需要配置预置容量，DynamoDB 会根据请求量自动伸缩，按照实际读写请求单元计费。两者在账户限制上的表现并不一致。
对于预置模式，DescribeLimits 返回的四个字段就是硬边界。如果创建表时指定的 ReadCapacityUnits 超过 TableMaxReadCapacityUnits，或者当前账户所有预置表读容量总和加上新表读容量后超过 AccountMaxReadCapacityUnits，API 会直接返回 LimitExceededException。写容量同理。这种限制在创建表、更新表容量、批量建表以及执行 UpdateTable 时都会生效。
按需模式表没有预置容量这一说，因此不会受到单个表的 RCU/WCU 上限限制。但按需模式仍然有账户级别的吞吐上限，这个限制由 DynamoDB 服务根据账户历史用量动态调整，并不会通过 DescribeLimits 返回。新账户的按需吞吐默认上限通常较低，首次访问按需表时还可能触发 BurstCapacity 相关的初始突发容量限制。若按需请求量突然翻倍，账户级吞吐上限可能来不及自动提升，导致写入或读取被拒绝。此时需要联系 AWS Support 提升按需容量上限，或者将核心表切换回预置模式并合理规划容量。
四、触发限制的典型场景与提升策略
最容易触发账户级限制的场景之一是大规模建表。例如数据迁移方案中按租户拆分几十张表，或者做蓝绿部署时同步创建一批新表。即使每张表的预置容量不高，但总数累加后很容易逼近账户上限。另一个常见场景是大促前的集中扩容，多张表同时执行 UpdateTable，累计新增容量超过账户剩余额度后，后面的扩容请求会失败。
当监控数据显示当前预置容量使用率已经超过 80%，或者业务预期未来一个月会有明显增长时，就应该着手申请提升限制。提升操作不能在控制台自助完成，需要进入 AWS Support 中心创建工单，选择 Service Limit Increase 类型，明确填写区域、资源类型、当前限制值、请求提升到的目标值以及业务峰值说明。对于 DynamoDB，通常需要同时说明账户级读/写容量上限和单表容量上限是否需要调整。
提交前最好准备好以下信息：当前账户所有预置表的读容量总和、写容量总和、最高的单表预置容量、过去两周的 CloudWatch 消费峰值、未来业务的 QPS 预估。这些数据能显著加快审批速度。一般情况下，账户级上限可以提升到数十万甚至上百万容量单元，但单表上限的调整会更谨慎，AWS 会评估底层分区的分布能力后再批准。
五、容量规划中的常见误区
第一个误区是把 DescribeLimits 的返回值和实际消费量混为一谈。账户级上限是配置上限，不是流量上限。即使当前没有任何请求，只要预置容量配置很高，同样会占用账户额度。很多团队习惯在创建表时直接设置很高的 RCU/WCU 以防万一，结果账户额度被快速占满，真正需要扩容时反而没有空间。合理做法是按实际峰值的 1.2 到 1.5 倍设置预置容量，再配合 CloudWatch 告警动态调整。
第二个误区是认为按需模式完全没有限制。按需表虽然不需要指定预置容量，但账户仍会受到按需吞吐上限的约束，且这个上限不会在 DescribeLimits 中体现。对于流量波动极大、难以预估的业务，按需模式可以减少容量规划负担，但当账户吞吐上限成为瓶颈时，同样需要提交工单提升。因此，混合使用两种模式时，要分别建立容量台账，不能只盯着 DescribeLimits。
第三个误区是忽视了区域之间的独立性。DynamoDB 的账户限制是按区域隔离的，同一账户在 us-east-1 和 ap-southeast-1 的限制可能不同，提升限制也需要按区域分别申请。多区域部署时，要针对每个区域单独执行 DescribeLimits，并根据各区域的实际流量分布制定不同的容量策略。把所有区域的容量想加在一起与某个区域上限比较，是实践中常见的计算错误。
总的来说，DescribeLimits 是容量规划的起点，而不是终点。它能快速告诉你账户和单表的预置容量天花板，但真正要做好容量管理，还需要结合预置使用率统计、CloudWatch 消费监控、按需模式额度以及业务增长预期，形成一套可持续的容量评估机制。只有把这些信息整合起来，才能在流量增长前主动扩容，避免线上请求因为容量不足而被限流。
DynamoDB DescribeLimits账户限制预置吞吐修改时间：2026-10-02 20:22:03