使用PITR恢复DynamoDB表后，如何更新CloudFormation/CDK等服务引用？

针对你提到的以DynamoDB为核心、用TypeScript CDK管理的AWS架构，结合PITR恢复的特性，逐个解答你的疑问：

1. 关于新表创建后的AWS文档缺失 #

AWS官方文档其实覆盖了PITR恢复后的新表配置细节，可能你没定位到对应章节。恢复生成的新表会继承原表的PITR设置，但不会自动继承原表的全局/本地二级索引、DynamoDB Streams、触发器、自定义KMS加密密钥等附加配置。你需要手动在新表上重新配置这些功能，或者通过CDK代码定义这些配置后部署到新表。

2. 如何更新所有关联服务对新表的引用 #

因为你用TypeScript CDK管理资源，最高效的方式是：

• 确保CDK代码中所有关联服务（Lambda、Kinesis、Firehose）对DynamoDB表的引用，都是通过CDK构造的变量/属性（比如table.tableArn、table.tableName），而非硬编码值
• 当新表创建后，在CDK代码中替换原表的构造实例为新表的信息（如果是通过控制台恢复的新表，需要在CDK中导入其ARN/名称；如果是通过CDK触发的恢复，可以直接更新表的定义）
• 执行cdk deploy重新部署栈，CDK会自动更新：
  • Lambda的环境变量、代码中注入的表引用
  • Kinesis/Firehose的目标配置（如果依赖DynamoDB Streams）
  • IAM角色中涉及原表的权限规则，替换为新表的ARN
• 注意：如果Lambda代码中存在硬编码的表名，必须修改代码并重新部署Lambda函数。

3. 是否应删除旧表并导入恢复的数据 #

绝对不要直接删除旧表：

• PITR恢复的新表已经包含指定时间点的完整数据，无需额外导入
• 保留旧表作为应急备份，直到新表运行稳定、所有关联服务切换完成且验证无误
• 确认新表无问题后，建议先对旧表创建手动快照备份，再删除旧表

4. 是否必须停机才能完成恢复 #

不需要强制停机，可通过蓝绿部署/流量渐变切换实现低风险甚至零停机恢复：

• 第一步：通过PITR恢复出目标时间点的新表，配置好所有必要的附加功能（索引、流等）
• 第二步：用CDK部署一套关联服务的“副本”指向新表，或者修改现有服务的配置，逐步将流量切换到新表（比如先让测试流量走新表，再切部分生产流量，最后全量切换）
• 第三步：验证新表和服务运行正常后，再下线旧表和依赖旧表的服务
• 若你的服务是无状态、支持动态切换数据源的，完全可以做到零停机；如果有强一致性要求，可能需要短暂的停机窗口切换，但可控制在分钟级。

5. 标准或最佳实践 #

• IaC优先：所有资源依赖均通过CDK抽象管理，杜绝硬编码表名/ARN，确保切换时只需修改一处配置
• 蓝绿部署：始终用新资源承接流量，避免直接替换旧资源，降低恢复风险
• 多层验证：恢复新表后先校验数据完整性（比如对比条目数、核心数据），再验证关联服务功能，最后全量切换流量
• 留存备份：旧表至少保留72小时以上，且删除前必须创建手动快照
• 定期演练：每季度至少测试一次PITR恢复和服务切换流程，确保团队熟悉操作
• 动态配置：关联服务通过SSM参数存储、环境变量获取表信息，而非代码硬编码，提升灵活性

内容的提问来源于stack exchange，提问作者Eduardo Elias Saléh