AWS Amplify CLI 中处理 CloudFormation 回滚失败的实战经验

问题背景

在使用 AWS Amplify CLI 进行环境升级时，开发者可能会遇到一个棘手的问题：当从开发环境(dev)向预发布环境(staging)推送变更时，如果 AWS 凭证权限不足导致推送失败，CloudFormation 堆栈可能会陷入 UPDATE_ROLLBACK_FAILED 状态。这种情况尤其常见于涉及 Cognito 用户池(UserPool)的认证服务变更场景。

问题现象

当推送操作因权限不足失败后，CloudFormation 堆栈会进入 UPDATE_ROLLBACK_FAILED 状态，错误信息通常显示类似"以下资源更新失败：[UserPool]"。此时，常规的推送操作和回滚操作都会受阻，而开发者往往不希望删除整个堆栈，因为其中可能包含重要的数据库和用户数据。

技术分析

这种问题本质上是一个 CloudFormation 堆栈状态管理问题。当 Amplify CLI 尝试更新资源但遇到权限错误时，CloudFormation 会自动触发回滚操作。但如果回滚过程中某些资源无法正确处理，堆栈就会卡在 UPDATE_ROLLBACK_FAILED 状态。

解决方案

经过实践验证，可以通过以下步骤解决此问题：

1. 选择性跳过资源回滚：在 CloudFormation 控制台中，找到"继续回滚"选项，在高级设置中选择"跳过资源"。需要逐一尝试跳过不同的资源，同时观察事件日志来判断哪个资源是导致回滚失败的关键。

2. 增量式变更推送：成功回滚后，如果变更包含多个新创建的全局二级索引(GSI)，建议采用增量式推送策略：

   • 先注释掉所有新增的索引
   • 逐个取消注释并推送
   • 每次只添加一个索引并执行推送操作

3. 权限检查：确保执行推送操作的 AWS 凭证具有足够的权限，特别是对 Cognito 用户池的操作权限。

最佳实践建议

1. 环境升级前检查权限：在跨环境推送前，务必验证目标环境的 IAM 权限设置是否完备。

2. 小步快跑式变更：对于包含多个资源变更的情况，建议拆分成多个小变更分批推送，降低失败风险。

3. 监控 CloudFormation 事件：在推送过程中密切关注 CloudFormation 事件日志，可以快速定位问题源头。

4. 备份重要数据：虽然 Amplify 提供了数据保护机制，但在进行重大变更前手动备份关键数据仍是明智之举。

总结

AWS Amplify CLI 与 CloudFormation 的深度集成为开发者提供了强大的基础设施即代码能力，但也带来了状态管理的复杂性。理解 CloudFormation 的状态转换机制和掌握回滚技巧，是每个使用 Amplify 的开发者应该具备的核心能力。通过本文介绍的方法，开发者可以有效地从 UPDATE_ROLLBACK_FAILED 状态中恢复，保障业务的连续性。