我在使用AWS Batch时多次碰到过作业卡在RUNNABLE状态的情况，结合你提到的环境（0-256台m3.medium按需实例、作业要求1vCPU+3GB内存），除了官方文档提到的“资源不足”，还有这些容易被忽略的原因：

• EC2按需实例账户配额限制：AWS每个区域对不同实例类型有默认配额（比如m3.medium默认可能只有20台），如果你的作业需要的实例数量超过了账户配额，计算环境无法扩容到足够的实例数，作业就会一直卡在队列里。你可以登录EC2控制台，在「配额」页面查看当前m3.medium实例的配额和已使用量，必要时提交配额提升申请。

• 计算环境与作业队列的关联异常：确认你的作业队列是否正确绑定了目标计算环境，同时检查计算环境的状态是否为ENABLED。如果计算环境被误设为DISABLED，或者队列绑定了其他资源不足的计算环境，作业自然无法被调度。

• 实例启动的隐性障碍：

  • 当前区域/可用区的m3.medium实例库存不足，AWS无法按需创建新实例。这种情况可以尝试切换到其他可用区，或者查看AWS状态页面确认是否有区域资源告警。
  • 计算环境的启动模板配置错误：比如使用了不兼容Batch的AMI、子网IP地址耗尽、安全组规则阻止了Batch服务与实例的通信（比如没允许Batch的服务IP访问实例的特定端口），导致实例启动后无法注册到计算环境，作业无法分配到实例。

• 作业资源配置与实例实际可用资源不匹配：m3.medium实例的总内存是3.75GB，但Batch会预留一部分内存给系统进程，实际可分配给作业的内存可能略低于3GB。如果你的作业严格要求3GB内存，Batch会判定该实例无法满足资源需求，不会调度作业。可以尝试将作业的内存要求调低一点（比如2.8GB），或者检查计算环境的实例资源预留设置。

• Batch服务配额限制：除了EC2实例配额，AWS对Batch也有并发作业数、队列容量等配额。如果你的队列中同时运行的作业数已经达到了账户的并发作业配额，即使有空闲资源，新作业也会卡在RUNNABLE状态。可以在AWS控制台的「服务配额」页面搜索Batch相关配额进行检查。

• 依赖项的隐性问题：虽然官方说明作业无未完成依赖项，但有时候依赖作业的状态更新可能存在延迟，或者依赖配置有误（比如依赖的作业ID输入错误），导致Batch认为作业仍有未完成的依赖。可以检查作业的依赖列表，或者尝试重新提交作业。

• Batch服务临时故障：偶尔AWS Batch会出现区域级的服务延迟或故障，导致作业调度流程卡住。可以查看AWS状态页面确认Batch服务是否正常运行。

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