AWS CodePipeline如何实现S3触发事件串行执行、前次成功后启动下一次

方案1：SQS + Lambda + EventBridge 组合方案（高可靠、适用于高触发频率场景） #

• 第一步：修改原有S3事件触发器的目标为标准SQS队列，不再直接触发CodePipeline。可根据业务需求设置队列消息保留周期（最长支持14天）避免突发事件丢失，同时可开启死信队列用于处理超过最大接收次数的异常消息。
• 第二步：开发调度Lambda函数，核心逻辑覆盖三个场景：
  1. 调用CodePipeline的get_pipeline_executionAPI查询目标流水线的当前运行状态，判断是否存在InProgress状态的执行实例
  2. 如果流水线处于空闲状态，从SQS队列拉取1条消息，解析出S3事件对应的Object版本、触发参数等信息，调用start_pipeline_execution接口启动流水线，同时将本次流水线执行ID和消息的receipt handle存入DynamoDB小表做关联
  3. 如果流水线正在运行，直接终止本次Lambda调用，不做额外操作
• 第三步：配置EventBridge规则，监听CodePipeline的执行状态变更事件，仅匹配SUCCEEDED和FAILED状态的事件，将规则目标设置为上述调度Lambda函数。
• 补充容错逻辑：收到流水线执行成功的事件后，Lambda先从DynamoDB查询对应receipt handle，调用delete_message接口删除已处理完成的SQS消息，再重新检查队列是否有新的待处理消息，存在则继续启动下一次流水线执行；如果收到流水线执行失败的事件，可根据业务需求选择重试当前消息、直接删除消息或者将消息推送到死信队列触发人工告警。

方案2：CodePipeline自带并发限制（轻量场景适用） #

• 直接将目标CodePipeline的Concurrent execution limit（并发执行限制）设置为1，此时即使同时收到多个启动请求，CodePipeline会自动将后续1个请求放入内置队列串行执行。
• 该方案局限性：CodePipeline内置队列最多仅支持存储1个待执行请求，超过的请求会直接被拒绝返回错误，仅适合触发频率极低、不会连续出现2个以上触发事件的场景。

• 如果需要保留所有触发事件的上下文，建议在SQS消息体中完整存储S3事件的Object键、版本ID、触发时间等字段，后续流水线执行时直接读取对应版本的代码，避免S3对象覆盖导致的执行逻辑错误。
• 调度Lambda需要添加异常捕获逻辑，如果调用CodePipeline接口失败，不要删除SQS消息，等待下一次调度重试，最大重试次数可与SQS的最大接收次数对齐。
• 有流程追溯需求时，可将每个事件的处理状态（排队中/执行中/成功/失败）存入DynamoDB表，方便后续问题排查。
• 如果业务允许连续重复事件去重，可在调度Lambda中增加事件去重逻辑，同一类修改事件仅拉取最新的一条执行，减少不必要的流水线运行成本。

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