大规模将DynamoDB表从预置吞吐量切换为按需吞吐量方案咨询

核心疑问解答：转换耗时和数据量的关系 #

DynamoDB预置模式转按需模式的耗时和表存储的数据量完全无关。该操作是AWS后台的异步元数据变更操作，不会触发表数据的扫描或迁移，正常情况下单表转换实际在3~10分钟内即可完成，你测试到的单表30分钟耗时是Terraform AWS Provider默认的更新超时轮询逻辑导致的，并非实际转换需要这么久。 #

现有方案评估与优化 #

方案1：并行Jenkins单表任务 #

• 原有方案优化点：
  • 先给所有DynamoDB表的Terraform资源块增加超时配置，缩短等待时间：

    resource "aws_dynamodb_table" "your_table" {
      # 原有配置保持不变
      timeouts {
        update = "15m"
      }
    }
    

  • 若可临时申请调高Jenkins并发配额到25，22个任务并行可在15分钟内完成全部转换；如果保持10并发，分3批执行总耗时也在45分钟以内，远低于串行执行的11小时。
  • 优势：完全不改动Terraform状态逻辑，风险极低，可直接对接现有部署流水线。

方案2：CLI操作+Terraform状态导入 #

• 原有方案风险点优化：不要删除整份Terraform状态文件，仅移除对应表的状态条目，操作步骤如下：
  1. 批量执行CLI命令触发所有表转换：aws dynamodb update-table --table-name <表名> --billing-mode PAY_PER_REQUEST
  2. 并行等待所有表转换完成，可调用aws dynamodb wait table-exists --table-name <表名>做状态校验
  3. 执行terraform state rm aws_dynamodb_table.<表资源名>逐个移除22个表的本地状态
  4. 执行terraform import aws_dynamodb_table.<表资源名> <表名>逐个导入更新后的表资源
• 优化后方案总耗时可控制在20分钟以内，风险远低于删除整份状态文件的操作。

更优替代方案：直接使用Terraform原生并发参数 #

无需拆分Jenkins任务，直接在执行Terraform apply时指定并行度参数即可，命令如下：

terraform apply -parallelism=10

Terraform默认并行度是10，刚好匹配你当前Jenkins环境的并发限制，会同时对10个表执行更新操作，全程自动维护状态一致性，不需要额外开发任务或脚本，风险和方案1一致，操作成本为0，总耗时和分批执行Jenkins任务的耗时基本持平。 #

生产操作注意事项 #

• 转换操作不会阻塞表的正常读写，业务侧无感知，无需安排停服窗口
• AWS限制表完成计费模式切换后，24小时内不能切换回预置吞吐量模式，请提前确认业务侧无回退需求
• 主表切换计费模式后，关联的所有全局二级索引（GSI）会自动同步切换，无需单独操作

内容的提问来源于stack exchange，提问作者railsdog