AWS Step Functions如何直接校验DynamoDB员工薪资记录更新状态

完全可以通过Step Function原生能力实现这个校验逻辑，不需要额外开发自定义Lambda做轮询，靠原生服务集成加内置的流程控制就能搞定，具体实现逻辑如下：

• 首先配置DynamoDB原生集成的查询任务
  直接在Step Function里添加调用DynamoDB Query的任务节点，按你表上的部门ID索引（如果没建部门ID对应的GSI建议先建，不然全表Scan效率太低）拉取对应部门的员工记录，查询时直接加FilterExpression过滤出Salary_Status <> :targetStatus的记录，这里:targetStatus填你要校验的目标值（注意你题目里前后写的状态值有Processed和Paid两种，提前统一枚举值避免逻辑出错）。如果单部门员工数较多，记得配置分页参数，避免触发DynamoDB单次查询1MB的返回上限。
• 接着加分支判断节点
  拿到Query返回结果后判断返回的Count字段：
  • 若Count = 0，说明该部门下没有不符合状态要求的员工，直接流转到后续的doFoo()节点即可
  • 若Count > 0，说明仍有员工薪资状态未更新完成，进入等待逻辑
• 最后配置等待+循环逻辑
  加内置的Wait状态设置合理的轮询间隔（建议10秒以上，别太频繁消耗DynamoDB读容量），等待结束后跳转回之前的DynamoDB查询节点重新拉取状态，直到满足Count=0的退出条件。

落地时几个避坑点：

1. 给Step Function的执行角色提前配好对应DynamoDB表的查询权限，不然运行时会报权限异常
2. 循环一定要加最大超时限制，比如设置最多运行24小时，超时直接走异常通知分支，避免某条记录一直卡在非目标状态导致工作流无限运行产生额外费用
3. 如果不想用轮询方案，也可以搭配DynamoDB Streams+EventBridge做事件驱动的触发，但这种方案不是纯Step Function内闭环的实现，如果你要求全流程收敛在单个工作流里，前面的轮询方案配置成本最低、稳定性也足够。

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