The same GitHub Actions label can now run on AWS
A GitHub Actions job that worked yesterday could fail at an external login today without any useful YAML diff. On October 28, GitHub announced a broader Linux compute pool spanning AWS as well as Azure. The label describing a job can stay the same while the address seen by an external service changes.
A larger pool of machines, behind familiar labels
The rollout covers standard 2-core and 4-core Linux runners and compatible larger runners of those sizes without specialized configurations. Windows and runners with private networking or other specialized setups are excluded. Eligible Free, Pro and Team runners participate automatically; Enterprise Cloud customers can enable AWS compute under Enterprise settings > Actions > Hosted compute cloud providers.
GitHub schedules eligible jobs across available providers without changing existing labels or workflow syntax. The intended gains concern capacity-related queues and resilience. That is not a measured speedup for your particular job or a promise that each job runs twice across clouds. Capacity improvements and application-level performance still need separate evaluation.
Why failures may look intermittent
Imagine a deployment API that accepts only Azure source addresses. The same workflow might connect from Azure and be rejected from a different outbound address in the expanded pool. GitHub also calls out network conditions in Microsoft Entra Conditional Access. This is an explanatory scenario, not a report of an incident we experienced.
Before replacing tokens or rebuilding the workflow around one cloud, compare the failed connection time, destination, source IP and destination policy. A job waiting for capacity and a running job failing authentication occur at different stages. Distinguishing them avoids treating a network denial as an expired token or assuming that more compute fixes an access policy.
An IP list is a set of ranges
The official starting point is the actions array in GET https://api.github.com/meta. The REST documentation explicitly says to query the API for current values rather than copy its examples. CIDR describes a range, so string equality is insufficient. Our Python ipaddress example uses documentation-only 192.0.2.0/24: 192.0.2.10 and 192.0.2.200 belong; 198.51.100.10 does not. These are neither live runner addresses nor service logs.
Importing every actions range is not the right architecture everywhere. The runner reference discourages using the numerous standard-runner ranges as an allowlist for internal resources, and points to larger runners with static IPs or self-hosted runners. A source network also does not identify a caller by itself. Preserve authentication and least privilege while deciding whether broad compute flexibility or a controlled egress fits the service.
A stable label can hide a changed assumption
The useful lesson is that CI infrastructure can evolve without a repository edit. Locate the failure before or after job startup, then compare any network restrictions with current published ranges and actual policies. Where a fixed exit address is a requirement, choose infrastructure designed for it. A runner label should not silently stand in for a particular cloud provider.