如何捕获AWS Amplify构建部署的成功/失败状态事件

目前生产环境验证过的可行方案有3种，优先选第一种无服务器事件驱动方案，稳定性最高、维护成本最低。

方案1：EventBridge 原生事件监听（首推） #

Amplify 所有构建、部署的生命周期事件默认会上报到EventBridge，不需要在Amplify侧做额外开启配置，直接配规则消费即可：

• 进入EventBridge控制台新建事件规则，事件源指定为aws.amplify
• 规则匹配条件过滤你需要的状态变更事件，覆盖全流程节点：构建启动、构建成功、构建失败、部署启动、部署成功、部署失败
• 规则触发目标绑定你编写的Lambda函数，函数逻辑只需要两步：
  • 解析事件payload里的应用名、分支名、commit信息、触发来源、失败阶段、构建详情页地址等字段
  • 调用你已经对接完成的Telegram Bot接口，把格式化后的状态消息推送到目标会话

实测事件延迟在3秒以内，EventBridge自带失败重试和死信队列机制，基本不会丢事件，线上用这个方案跑1年多基本没出过问题。
可直接复用的事件匹配规则示例：

{
  "source": ["aws.amplify"],
  "detail-type": ["Amplify Build Status Change", "Amplify Deployment Status Change"],
  "detail": {
    "appId": ["替换为你的Amplify应用ID"]
  }
}

方案2：Amplify 自定义Webhook回调 #

如果不想配置EventBridge，可以直接用Amplify自带的Webhook能力：

• 先准备一个公网可访问的HTTP接收接口，直接用Lambda函数URL或者你现有服务的接口都可以
• 进入Amplify控制台对应应用的「通知」-「Webhook」配置页，添加你的接口地址，勾选需要接收的构建、部署状态事件
• 接口收到Amplify发来的POST请求后，解析事件内容直接转发给Telegram Bot即可

注意这个方案没有内置重试机制，要是你的接收接口临时不可用，事件会直接丢失，稳定性比EventBridge方案差。

方案3：API定时轮询（兜底方案，非必要不选） #

如果因为账号权限限制配不了前两种方案，可以用轮询方式兜底：

• 配置定时触发任务（比如CloudWatch Events每5分钟触发一次Lambda）
• 任务逻辑里调用Amplify的ListJobs接口拉取对应应用最近的构建、部署记录
• 本地缓存已经推送过的任务ID，识别到未推送的成功/失败状态时，推送消息到Telegram

这个方案存在分钟级延迟，还要自己实现去重逻辑，长期维护成本高，只适合权限受限的临时场景。

实用配置提示 #

• 推送失败类消息时，记得把事件里带的失败阶段（代码拉取/依赖安装/构建执行/资源部署）、错误日志片段一起带上，不用点进控制台就能快速定位问题
• 事件默认会包含PR预览环境的构建记录，要是不需要这类通知，记得在事件匹配规则里加过滤条件，避免无关消息轰炸
• 消息里可以直接拼接Amplify构建详情页的跳转地址，点链接就能直接看完整日志，省掉手动找对应构建记录的步骤

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