AWS CloudFormation小变更致栈回滚：如何规避及解决？

为什么修改DynamoDB键会导致整个栈崩溃？ #

DynamoDB的分区键/排序键属于资源核心属性，一旦创建后无法直接修改。CloudFormation处理这类变更时，会执行「删除原表 → 创建新表」的替换操作。如果该表与其他资源（如Lambda函数、API Gateway、关联下游服务）存在依赖关系，删除原表会触发依赖资源的级联删除逻辑。若其中某一步失败（比如带数据的S3桶默认不允许删除），整个变更集执行中断并触发回滚；如果回滚过程中部分资源无法恢复到变更前状态，最终栈会停在Rollback_complete状态，只能手动清理残留资源后删除栈。

CloudFormation的失败处理相关参数与配置 #

1. DeletionPolicy 和 UpdateReplacePolicy #

这是最关键的资源级配置，直接控制资源在删除或替换时的行为：

Resources:
  MyDynamoDBTable:
    Type: AWS::DynamoDB::Table
    Properties:
      # 表属性配置
    DeletionPolicy: Retain  # 删除栈时保留该表
    UpdateReplacePolicy: Retain  # 变更需要替换表时，保留旧表

设置后，即使CloudFormation尝试替换DynamoDB表，旧表会被保留，不会触发级联删除，避免数据丢失和连锁故障。

2. 栈策略（Stack Policy） #

通过栈策略可以限制CloudFormation对特定资源的操作，防止意外删除或修改关键资源：

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

当尝试修改DynamoDB主键触发替换操作时，CloudFormation会直接报错终止变更，不会执行后续删除逻辑，避免影响其他资源。

3. 回滚配置（RollbackConfiguration） #

在创建变更集时，可以配置基于CloudWatch告警的自动回滚，提前监控变更后的异常：

RollbackConfiguration:
  RollbackTriggers:
    - Arn: arn:aws:cloudwatch:region:account-id:alarm:MyAlarm
      Type: AWS::CloudWatch::Alarm
  MonitoringTimeInMinutes: 60

当指定的告警触发时，CloudFormation会自动回滚变更，减少故障持续时间。

4. 终止保护（Termination Protection） #

给栈开启终止保护，防止意外删除整个栈：

aws cloudformation update-termination-protection --stack-name MyStack --enable-termination-protection

注意：这仅保护栈不被删除，无法阻止变更过程中的资源删除。

其他预防方案 #

• 变更预览：每次变更前用aws cloudformation create-change-set生成变更集，仔细核对所有会被修改、删除、创建的资源，确认无意外操作后再执行变更。
• 拆分大型栈：将大型栈拆分为多个独立小栈（比如数据存储栈、业务逻辑栈、前端资源栈），减少单个变更的影响范围，即使某个栈失败，其他栈不受影响。
• 数据备份：给DynamoDB开启自动备份与点-in-time恢复，给S3桶开启版本控制与生命周期规则，确保数据可恢复。
• 增量变更：每次只做一个小范围的变更，验证无误后再进行下一个变更，降低故障风险。

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