AWS让DynamoDB批量写入条目正式可用：用独立容量把S3文件装入已有表，美国东部每GB 0.10美元起，但无条件记录会覆盖已有条目、流消费者仍会看到写入、上线时不支持全局表

2026年11月5日，AWS宣布Amazon DynamoDB的批量写入条目（bulk put items）正式可用。这是一项托管功能，把Amazon S3里的数据写入已有的表。此前，要把其他系统生成的文件装进一张正在服务的表，通常要自建管道、用AWS Glue或Amazon EMR做作业，还要小心管理表的容量。现在只需把DynamoDB指向输入文件的S3位置，指定报告的输出位置并选择档位。公告说这些写入不会影响现有工作负载；发布博客和开发者指南则说它们使用独立容量，不消耗表的读写容量。

输入文件是按行分隔的DynamoDB JSON或Amazon Ion，可选gzip或zstd压缩。每条记录可以带自己的条件表达式，语法与PutItem相同。对分区键使用attribute_not_exists可以实现只插入的写入，对版本属性做比较则只在传入副本更新时才写入。同一个文件里可以混合无条件、只插入和版本保护的记录。有两点要注意：没有条件的记录会无条件写入，并覆盖相同键的现有条目；如果所有条目都要遵守同一个条件，这个条件必须写在文件里的每条记录上。被条件跳过的条目不算失败，它计入已处理数量，并且在你请求条件检查失败类型时出现在报告中。

整个操作是异步的。启动调用返回操作ARN，并带有客户端令牌，重试启动不会产生重复的导入；最初几分钟用于准备资源，所以计数器一开始可能为零。启动者需要账户级和表级权限、输入桶的读权限、报告桶的写权限以及相关的AWS KMS密钥权限。操作结束时状态为COMPLETED、COMPLETED_WITH_ERRORS、FAILED或CANCELLED。取消不会回滚已经写入的条目，所以取消后的表是部分更新的状态。报告列出未写入的记录，包括来源对象、对象中的位置和原因；对条件失败的记录，还会同时显示新条目和已有条目。博客建议把COMPLETED_WITH_ERRORS当作正常路径，修正错误记录后只重新导入这些记录。

有两个档位。Standard是默认档，价格更低，适合时间灵活的工作，例如定期补充数据和回填。Accelerated追求更高吞吐，适合有截止时间的工作，例如迁移和恢复。在表已充分扩展、高基数分区键空间均匀分布、输入拆成多个大小相近的S3对象、没有全局二级索引复制的前提下，AWS给出Accelerated的估算：1,000万个1 KB条目不到10分钟，1亿个不到1小时，10亿个需要2到4小时。AWS称这些只是示意性的起点。它还提醒，最初几次运行可能快过表的扩展，同一形状的文件要跑三到五次，完成时间才会趋于稳定。

计费按字节计算。在美国东部（弗吉尼亚北部），博客给出Standard每GB 0.10美元、Accelerated每GB 0.20美元，每个条目至少按1 KB计，表和每个索引分别计费。失败的条件检查仍然计费，被校验拒绝的条目不计费。同一篇文章给出1亿个1 KB条目的算例：Standard 10.00美元，Accelerated 20.00美元。我们只转述这个地区的数字；公告对其他地区指向了价格页。

限制很具体。每张表同一时间只能运行一个批量写入操作，正在创建索引时也不能运行。每个账户最多同时有五个Standard和五个Accelerated操作。单次操作在Standard档最多覆盖100 GB，在Accelerated档最多1 TB，目标表必须处于活动状态。上线时不支持全局表，操作运行期间也不能给表添加副本。带向量索引的表只支持Standard。该功能写入的是完整条目，不会更新单个属性，这类需求仍用UpdateItem。Standard在所有商业区域和AWS GovCloud（美国）区域可用，而Accelerated只在另一个页面列出的区域可用，所以不能把Standard的可用范围当成Accelerated的。

我们的判断：不影响现有工作负载这个说法，对表容量和应用的读写指标是成立的，但博客自己也列出了其他影响。导入的条目在DynamoDB Streams和Kinesis输出里与应用写入没有区别，所以大型导入可能压垮流的消费者，除非它们按额外吞吐量扩容，或者用MaxWriteRequestUnits限制操作的写入速率。博客警告，过低的上限会让运行超出时间限制而失败，但我们保存的页面都没有写明这个时间限制是多少。正在进行的事务对条目有优先权，导入会等待。由于批量写入不出现在已消耗容量的指标里，表上的告警不会告诉你导入出了问题，需要盯的是操作状态。只写几个条目时，PutItem和BatchWriteItem仍是合适的工具。