GitHub Actions加入多云计算池：符合条件的Linux作业可能在AWS运行，需更新IP允许列表

GitHub 于 2026 年 10 月 28 日表示，GitHub Actions 现在会把符合条件的作业调度到更广的多云计算池中，因此符合条件的 Linux 作业除了在 Microsoft Azure 上运行，也可能在亚马逊云科技（AWS）上运行。GitHub 的目标是增加容量、缩短因容量不足造成的排队时间，并在需求高峰时提高韧性。这是逐步推出的变更，并附有一项警告：只列出 Azure 或微软地址段的网络允许列表可能挡住新的运行器。

适用范围很窄。多云计算适用于标准的 2 核和 4 核 Linux 运行器，以及没有特殊配置、与之兼容的 2 核和 4 核大型运行器。它不适用于 Windows 运行器，也不适用于使用专用网络或其他特殊配置的运行器。GitHub 没有公布会迁移多少比例的作业、每个账户的开始日期，也没有给出实测的排队时间改善，所以好处目前只是目标，而不是结果。

谁能用上取决于套餐。使用 GitHub Free、Pro 和 Team 的客户，符合条件的运行器会自动使用多云计算。GitHub Enterprise Cloud 客户需要主动开启：管理员在企业设置的 Actions 下的“托管计算云提供商”中启用 AWS 计算。GitHub 说，它会自动在可用的提供商之间调度符合条件的作业，运行器标签和工作流语法保持不变。因此团队不能按作业选择云，只有在 Enterprise Cloud 上，才能选择是否允许使用 AWS 计算。

建议采取的行动，是可能让流水线出问题的部分。扩展后的池里，运行器使用额外的出站 IP 地址。只放行 Azure 或微软所有地址段的策略，包括 Microsoft Entra 条件访问策略，可能会阻止这些运行器的连接或身份验证。常见的受害者是访问有防火墙的数据库、私有包仓库，或会检查调用方地址的云接口的作业。由于是逐步推出，这类故障可能只在部分作业上间歇出现，而不是一次全部爆发，诊断起来更困难。

GitHub 的办法是不再维护某个云专属的地址列表。所有 GitHub Actions 运行器的 IP 地址段，包括新增的，都发布在 GET https://api.github.com/meta 返回结果的 actions 数组中。GitHub 建议让允许列表与该端点同步，而不是依赖某一家云的地址段，并建议现在就做，赶在工作流开始进入扩展池之前。由于公布的列表会变化，团队可以把同步写成脚本并定期运行。没有开启的 Enterprise Cloud 客户可以避开新地址，但更新日志没有说明这个选择会保留多久。

GitHub 把这次变更描述为扩展托管运行器背后的基础设施，目的是让工作流在需求高峰时也能更快启动、运行更可靠。更新日志用的是“可能”：符合条件的 Linux 作业“可能”在 AWS 上运行，并不是每个符合条件的作业都会去 AWS。企业客户的开关位于企业设置的 Actions 下的“托管计算云提供商”。运行器标签和工作流语法不变，意味着不必修改工作流文件，但网络策略需要修改。这个区别很容易被忽略：工作流层面毫无感觉，网络层面却有感觉。GitHub 还点名了 Microsoft Entra 条件访问这类按来源地址放行的身份策略，所以不只是防火墙团队，身份与访问管理团队也要参与核对。

对运维团队，一个可执行的检查顺序是：先在 Actions 日志里确认哪些作业的出口地址发生了变化，再比对 meta 端点返回的 actions 数组，最后更新防火墙、条件访问策略和云安全组。这个顺序是本站的建议，不是 GitHub 的原话。更新日志只要求把允许列表与 meta 端点保持同步，并指出所有运行器的地址段，包括新增的，都发布在该端点。另一个要点是这是滚动式变更，GitHub 建议在工作流开始进入扩展池之前就更新。本站的判断是，一旦开始，间歇性失败会更难复现。由于更新日志没有给出开始日期，团队无法等到某个日期再检查，最好现在就把允许列表与 meta 端点对齐。这样即使 Enterprise Cloud 客户暂不启用 AWS 计算，也已提前做好准备。

对多数团队来说，工作量小而具体：找出所有放行 GitHub 托管运行器的防火墙规则、条件访问策略和云安全组，把固定地址段换成 meta 端点的列表，并在推出开始后检查日志里是否有被拦截的连接。使用 Windows 运行器、特殊用途的大型运行器或专用网络的团队可以留意，这些都不在本次公告范围内。