如何回滚通过CloudFormation部署的AWS CodeStar Lambda函数？

我之前也踩过这个坑！CodeStar默认的Lambda部署逻辑确实会直接删除重建函数，把你手动创建的版本和别名全清掉，回滚只能靠Git重新推代码，效率太低了。下面是几个可行的解决方案，按落地优先级排序：

方案1：修改CodePipeline部署策略，改用Lambda增量更新而非重建 #

CodeStar生成的默认配置（不管是CloudFormation还是CodeDeploy），大概率用的是「替换整个Lambda函数」的更新方式。你需要调整部署逻辑，让它只更新函数代码，保留原有函数资源和版本记录：

• 若用CodeDeploy部署Lambda：

  1. 打开CodePipeline对应部署阶段，找到CodeDeploy的配置项
  2. 在部署组设置里选择「Lambda逐步部署」模式，确保部署时是更新现有函数而非创建新函数
  3. 配置完成后，每次部署会自动生成新的Lambda版本，同时你可以让指定别名（比如prod）自动指向新版本；回滚时直接在CodeDeploy控制台切换别名到旧版本即可，无需重新部署代码

• 若用CloudFormation直接部署：
  修改CloudFormation模板中AWS::Lambda::Function的UpdateReplacePolicy为Retain，同时新增AWS::Lambda::Version和AWS::Lambda::Alias资源来管理版本和流量入口。这样更新代码时只会生成新的版本记录，不会删除旧函数和已有的版本/别名。

方案2：添加自定义Post-Deploy动作，自动维护版本和别名 #

如果不想改动CodeStar的默认部署框架，可以在CodePipeline里加一个自定义阶段，用脚本自动创建版本和别名：

• 具体步骤：
  1. 在CodePipeline的Deploy阶段后新增一个阶段
  2. 选择「Invoke Lambda」作为动作类型，触发一个自定义Lambda函数
  3. 这个自定义Lambda的核心逻辑：
     • 获取刚部署完成的Lambda函数名称
     • 调用createVersion API生成新版本
     • 更新指定别名（比如prod）指向该新版本
     • 可选：保留最近N个旧版本，避免版本过多占用资源
  4. 回滚时，直接手动调用updateAlias API将别名切回目标旧版本号即可，无需重新推送代码

方案3：迁移到SAM/Serverless Framework，原生支持版本管理 #

如果是长期维护的微服务，推荐用AWS SAM或者Serverless Framework来替代CodeStar的默认部署逻辑，它们天生支持Lambda版本化和别名管理：

• SAM模板中可以直接定义AWS::Lambda::Version和AWS::Lambda::Alias资源，部署时自动生成版本记录，别名自动指向新版本
• 回滚时只需执行sam deploy --rollback，或者修改模板中别名的版本指向后重新部署，操作非常顺滑
• 你可以把现有CodeStar项目的代码迁移到SAM，再将CodePipeline调整为部署SAM模板，从根源解决版本丢失问题

应急回滚技巧（不用改配置的临时方案） #

如果现在急需回滚，又没时间调整部署配置，可以：

1. 打开Lambda控制台，找到目标函数的「版本」标签页
2. 找到之前保留的旧版本，手动创建新别名指向它，或者直接修改现有别名的版本指向
3. 这样流量会立刻切换到旧版本，无需等待CodePipeline重新部署

最后提醒：不管用哪种方案，一定要把别名作为流量入口（比如API Gateway指向别名而非直接指向函数），同时开启Lambda的版本跟踪，这样才能实现真正的无缝回滚。

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