GitHub Actions Runners Now Run on AWS: What Breaks

GitHub Actions jobs are no longer guaranteed to run on Microsoft Azure. Since Oct 28, 2026, GitHub schedules eligible Linux jobs across a multi-cloud compute pool, and those jobs may now run on Amazon Web Services. Your workflow YAML and runner labels don't change, but two things can break: network allowlists that only trust Azure or Microsoft IP ranges, and Azure SDK code that relies on DefaultAzureCredential.

For GitHub Free, Pro and Team accounts the change is automatic and rolling. GitHub Enterprise Cloud customers have to opt in. Here is what moves, what doesn't, and what to fix before your jobs land on AWS.

What changed on Oct 28

In its changelog post, GitHub says the expanded pool adds capacity, cuts capacity-related queue times and improves resilience during peak demand. The scope is deliberately narrow:

• In scope: standard 2-core and 4-core Linux runners, plus compatible 2-core and 4-core larger runners without specialized configurations.
• Out of scope: Windows runners, runners with private networking, and other specialized configurations. GitHub's docs say these, and Linux runners outside the pool, stay on Azure virtual machines. macOS runners stay in Azure data centers.
• Free, Pro and Team: eligible jobs use multi-cloud compute automatically.
• Enterprise Cloud: opt-in. Enterprise owners go to Policies, Actions, General, open the Policies tab, and under Hosted compute cloud providers choose Multi-cloud.

You cannot pick the cloud per job. GitHub says jobs are scheduled automatically across available providers, and labels such as ubuntu-latest keep working as before. That matters for everything that now runs on Actions, including GitHub Agentic Workflows, which went generally available the same day and compile to standard Actions YAML.

Problem 1: Azure-only IP allowlists

Runners in the expanded pool use additional outbound IP addresses. GitHub warns that policies allowing only Azure or Microsoft-owned ranges, including Microsoft Entra Conditional Access policies, can block connections or authentication from these runners. Because the rollout is gradual, a job can pass on Monday and fail on Tuesday depending on where it was scheduled.

The fix GitHub recommends is to sync your allowlists with the actions array returned by the meta API, not with a cloud provider's published ranges:

curl -s https://api.github.com/meta | jq '.actions | length'

When we ran that request on Oct 29, 2026, the actions array held 7,081 CIDR ranges, 1,528 of them IPv6. GitHub's runner reference says the list is updated once a week, and it explicitly does not recommend using these ranges as allowlists for internal resources. Its suggested alternatives are larger runners with a static IP address range, or self-hosted runners. If a firewall rule, database allowlist or Conditional Access policy is the only thing letting CI reach a private system, this is the week to move that job.

Problem 2: DefaultAzureCredential and the metadata address

This one is subtler. AWS EC2 and Azure both expose their instance metadata service at 169.254.169.254. GitHub's troubleshooting guide says some Azure Identity SDKs read the EC2 response as a failed Azure managed identity login, and stop the credential chain before they reach the Azure CLI session that azure/login created. The job can fail even though the login step succeeded, with an error such as:

DefaultAzureCredential: failed to acquire a token.
ManagedIdentityCredential authentication failed.
GET http://169.254.169.254/metadata/identity/oauth2/token
RESPONSE 401: 401 Unauthorized

GitHub's fix is to select AzureCLICredential explicitly when the app should use the azure/login session. For Go apps on azidentity 1.11.0 or later, you can set an environment variable on the step that runs the application:

- name: Run application
env:
AZURE_TOKEN_CREDENTIALS: AzureCLICredential
run: ./application

The other options are to construct AzureCLICredential directly in code, or to fully configure environment or workload identity credentials, which the SDK evaluates before managed identity. GitHub notes that a successful azure/login step does not by itself configure the SDK's workload identity credential. Support for narrowing DefaultAzureCredential varies by language and SDK version, so check yours. If you are moving CI off long-lived secrets at the same time, our piece on how GitHub Apps can now replace enterprise PATs covers the GitHub side of that cleanup.

What to check before your jobs move

• Search firewall rules, database allowlists, storage account network rules and Conditional Access policies for Azure-only or Microsoft-only ranges that CI depends on.
• Replace hard-coded ranges with a scheduled sync from the actions array, or move the job to a static-IP larger runner or a self-hosted runner.
• Grep your code for DefaultAzureCredential in anything that runs inside a workflow, and pin it to AzureCLICredential or workload identity.
• Watch for anything else that talks to 169.254.169.254 in CI, such as scripts that assume Azure metadata, since GitHub says the EC2 service answers at the same address.
• On Enterprise Cloud, do this before switching the Hosted compute cloud providers policy to Multi-cloud, which is the order GitHub's enterprise policy docs recommend.

None of this is new advice in isolation. CI runners have always been a place where credentials and network trust get tangled, which is why our guide to stopping AI coding agents from leaking secrets leans on short-lived, scoped credentials. The difference now is that the underlying cloud can change under an unchanged workflow file.

Why GitHub is doing this

GitHub frames the move as capacity and reliability: more providers, shorter queues at peak times, and a service that depends less on a single cloud. GitHub has not published queue-time figures or a timeline for the rollout, and it has not said whether more providers or runner types will join the pool. The change does fit a wider pattern of platforms abstracting away where compute runs, such as Vercel now deploying plain Dockerfiles, so teams increasingly need policies based on identity rather than on a cloud's IP space.

Verdict

For most repositories this is a free improvement: same labels, same YAML, potentially shorter waits. The risk sits with teams that quietly trusted Azure's network or metadata service. If your CI reaches private resources through IP allowlists, or authenticates to Azure with DefaultAzureCredential, treat this as a breaking change and fix it now. Free, Pro and Team users can't wait for an opt-in switch, and Enterprise Cloud owners should finish the checklist before enabling Multi-cloud.

Sources

• GitHub Changelog: GitHub Actions adds multi-cloud compute to improve reliability (Oct 28, 2026)
• GitHub Docs: Cloud hosts used by GitHub-hosted runners
• GitHub Docs: GitHub-hosted runners reference, IP addresses
• GitHub Docs: Troubleshooting workflows, Azure SDK authentication failures
• GitHub Enterprise Cloud Docs: Enabling multi-cloud compute
• GitHub REST API: meta endpoint (actions IP ranges)
• GitHub Changelog: GitHub Agentic Workflows generally available (Oct 28, 2026)