GitHub Actions Adds Multi-Cloud Compute: Eligible Linux Jobs May Run on AWS, so Update IP Allowlists

GitHub said on October 28, 2026 that GitHub Actions now schedules eligible jobs across a broader, multi-cloud compute pool, so eligible Linux jobs may run on Amazon Web Services as well as Microsoft Azure. GitHub's stated aims are more capacity, shorter capacity-related queue times and better resilience at peak demand. The change is rolling, and it carries a warning: network allowlists that name only Azure or Microsoft ranges can block the new runners.

The scope is narrow. Multi-cloud compute applies to standard 2-core and 4-core Linux runners and to compatible 2-core and 4-core larger runners without specialized configurations. It does not apply to Windows runners, and it does not apply to runners with private networking or other specialized configurations. GitHub does not publish a share of jobs that will move, a start date for each account, or any measured queue-time improvement, so the benefit is a stated goal, not a result.

Who gets it depends on the plan. Customers on GitHub Free, GitHub Pro and GitHub Team use multi-cloud compute automatically for eligible runners. Customers on GitHub Enterprise Cloud opt in: in Enterprise settings, under Actions, in Hosted compute cloud providers, an administrator enables AWS compute. GitHub says it schedules eligible jobs across the available providers automatically, and that runner labels and workflow syntax stay the same. A team therefore does not choose a cloud per job. It chooses only, on Enterprise Cloud, whether AWS compute is allowed at all.

The recommended action is the part that can break pipelines. Runners in the expanded pool use additional outbound IP addresses. A policy that allows only Azure or Microsoft-owned ranges, including a Microsoft Entra Conditional Access policy, can therefore block connections or authentication from those runners. Typical victims are jobs that reach a firewalled database, a private package registry or a cloud API that checks the caller's address. Because the rollout is gradual, such a failure could appear intermittently, on only some jobs, rather than all at once, which makes it harder to diagnose.

GitHub's fix is to stop maintaining cloud-specific lists. All GitHub Actions runner IP ranges, including the new ones, are published in the `actions` array of the response from `GET https://api.github.com/meta`. GitHub recommends syncing allowlists with that endpoint instead of relying on ranges from one cloud provider, and recommends doing it now, before workflows begin to run in the expanded pool. A team can script the sync and run it on a schedule, since the published list can change. Enterprise Cloud customers who do not opt in avoid the new addresses, but the changelog does not say how long that choice will stay available.

For most teams the work is small and concrete: find every firewall rule, conditional access policy and cloud security group that admits GitHub-hosted runners, replace fixed ranges with the meta endpoint's list, and check the logs for blocked connections after the rollout begins. Teams with Windows runners, larger special-purpose runners or private networking can note that these are outside the announcement.