AWS Step Functions性能咨询：极简状态机处理15k数据耗时超预期

你的场景很明确：用Express型状态机处理15k条记录，核心是无IO无计算的Pass状态，设了10000最大并发，预期1分钟内跑完但结果拉胯，还排除了SQS、DynamoDB、Lambda这些关联服务的影响。下面从配置和服务特性两个角度梳理可能的问题：

先查配置有没有踩坑 #

• 并发配额没到位：别光看状态机里设了10000并发，AWS账户有全局的Express状态机执行并发配额，默认值可能远低于这个数。去Service Quotas页面查一下你的账户配额，如果不够，赶紧提额——这是并发上不去最常见的原因。
• Map状态的隐性开销：如果是用Map状态批量处理15k条记录，得看你的ItemProcessor是内嵌的Pass还是单独的子状态机。内嵌的话，每条记录的状态转换都有小开销，15k条累加起来就很明显；要是用子状态机，还得考虑子状态机的启动延迟。
• S3读取拖了后腿：虽然后面是Pass状态，但从S3读15k条数据的前置阶段可能耗时比你预期的久。单独测一下S3批量读取的耗时，确认是不是数据加载阶段拖慢了整体进度。
• 日志拖慢执行：如果开了详细的CloudWatch日志，大量日志写入会占用额外资源，拖慢状态机执行速度。临时关掉日志或者降低日志级别，再跑一遍测试看看性能有没有回升。
• 区域资源紧张：不同AWS区域的Step Functions负载不一样，要是你测试的区域刚好资源紧张，并发跑不起来也正常。换个低负载的区域测一下做对比。

这算不算正常表现？ #

纯Pass状态的Map处理，15k条配10000并发，正常来说肯定能在1分钟内完成。如果排除了上面的配置问题还不行，大概率是临时的服务波动，但这种情况极少。几乎可以肯定是你没注意到的配置疏漏或者配额限制。

验证步骤建议 #

1. 先确认账户的Express状态机并发配额≥10000，不够就提交提额申请。
2. 把状态机简化到极致：去掉S3读取环节，直接传入预生成的15k条数据，只保留Map+Pass状态，测试执行耗时。
3. 查看CloudWatch指标：重点关注Throttles（节流）、ExecutionsStarted和ExecutionsSucceeded的速率，有没有并发上不去的迹象。
4. 测试不同并发值（比如5000、20000，配额允许的话），看性能是否随并发线性提升——如果到某个值就卡住，那就是配额或服务限制导致的。

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