生产环境使用AWS SAM定义DynamoDB表如何避免数据被删除重建？

核心风险说明 #

通过CloudFormation/SAM定义DynamoDB资源时，若修改了需要资源替换的属性（如表名、主键结构等），默认行为会直接删除旧表并创建新表，导致生产数据完全丢失。

业内通用防护方案 #

• 配置资源保留策略 #

  在DynamoDB资源定义中添加DeletionPolicy: Retain和UpdateReplacePolicy: Retain两个属性，是最基础的防护手段。配置后：
  • 栈删除时，DynamoDB表不会被同步删除
  • 出现需要替换资源的更新操作时，旧表会被保留，仅解除CloudFormation对该表的管理关系，不会删除数据
    SAM配置示例：

  Resources:
    YourDynamoDBTable:
      Type: AWS::DynamoDB::Table
      DeletionPolicy: Retain
      UpdateReplacePolicy: Retain
      Properties:
        # 其余表配置项
  

• 避免修改触发表替换的属性 #

  提前明确DynamoDB资源的不可变属性，生产环境上线后禁止修改这类属性，从根源避免触发表替换：
  • 表名TableName
  • 主键结构KeySchema
  • 本地二级索引的键定义
    若需要新增查询模式，优先新增全局二级索引（GSI），新增GSI属于原地更新，不需要替换表。

• 配置栈策略禁止意外替换删除 #

  为CloudFormation栈配置专属栈策略，明确禁止DynamoDB资源的删除和替换操作，即使模板被误改，部署也会直接被拦截。栈策略示例片段：

  {
    "Statement": [
      {
        "Effect": "Deny",
        "Action": ["Update:Replace", "Update:Delete"],
        "Principal": "*",
        "Resource": "LogicalResourceId/YourDynamoDBTable"
      },
      {
        "Effect": "Allow",
        "Action": "Update:*",
        "Principal": "*",
        "Resource": "*"
      }
    ]
  }
  

• 所有生产变更前预览变更集 #

  每次生产部署前必须生成CloudFormation变更集，检查变更操作中是否包含DynamoDB资源的Replace动作，确认无风险后再执行部署。

无需删表重建的实现方案 #

完全可以做到保留旧表无需删重建。如果确实需要调整原表的不可变属性，按以下步骤操作即可：

1. 先给模板中现有DynamoDB资源添加DeletionPolicy: Retain和UpdateReplacePolicy: Retain，部署更新
2. 把DynamoDB资源从模板中移除，再次部署，此时旧表会保留，不再受CloudFormation管理
3. 在模板中定义新的符合需求的DynamoDB表，部署创建新表
4. 通过DynamoDB导出导入功能或者DynamoDB流同步旧表数据到新表，业务切流到新表后再手动清理旧表

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