"Cloud: AWS" in Set up job: GitHub-hosted Linux runners also run on AWS since October 28, 2026, and what can fail there
Since October 28, 2026, GitHub Actions schedules eligible Linux jobs on Amazon Web Services as well as Microsoft Azure (GitHub changelog). It covers standard 2-core and 4-core Linux runners, such as ubuntu-latest, and compatible larger runners. It is automatic on GitHub Free, GitHub Pro and GitHub Team, and an opt-in on GitHub Enterprise Cloud. Labels and workflow files do not change, so a job can run on either cloud from one run to the next. Most jobs do not notice. The ones that do depend on the network or the machine: an allowlist of Azure IP ranges, the Azure SDK's managed identity, a script that expects a particular apt source, or a step that needs to start fast.
Which cloud a job ran on
Open the job, then Set up job. The group "Runner Image Provisioner" names the cloud and the region. A job on AWS (JPHutchins/code-review #359, October 31, 2026):
Runner Image Provisioner Hosted Compute Agent Version: 20261015.610 Region: us-east-1 Cloud: AWS
A job on Azure shows, for example, Region: eastus and Cloud: Azure. Re-running a job can move it to the other cloud, so a failure that comes and goes on re-runs is worth comparing with this line.
Which runners
- Can run on AWS: standard 2-core and 4-core Linux runners, and compatible 2-core and 4-core larger runners without specialized configurations.
- Stay on Azure: Windows runners, and runners with Azure private networking or other specialized configurations. macOS runners are not part of it.
- GitHub Free, GitHub Pro and GitHub Team: automatic. GitHub Enterprise Cloud: an enterprise owner opts in under Enterprise settings, Policies, Actions, General, Hosted compute cloud providers, by enabling AWS compute.
IP allowlists, firewalls and Conditional Access
Runners in the AWS pool connect from other outbound IP addresses. GitHub's documentation says that policies that allow only Azure or Microsoft-owned ranges, including Microsoft Entra Conditional Access policies, can block connections or authentication from these runners. A database firewall, a WAF in front of an API, or a service principal's sign-in behind a location policy then fails from the jobs that land on AWS, and passes from the jobs that land on Azure.
All the ranges, the new ones included, are in the actions array of GitHub's meta API, which GitHub updates once a week:
curl -s https://api.github.com/meta | jq -r '.actions[]' | wc -l
On November 5, 2026 it listed 8,350 ranges, 5,622 of them IPv4. 22 of the IPv4 ranges were inside the ranges Amazon publishes for AWS, such as 3.41.210.0/24; an allowlist built from Azure's ranges misses them. GitHub says to keep an allowlist in sync with the whole actions array rather than with a cloud provider's ranges, and, since there are so many, not to use it for internal resources at all: use larger runners with a static IP address range, or self-hosted runners.
"ManagedIdentityCredential authentication failed" from the Azure SDK
AWS EC2 and Azure both serve their instance metadata at 169.254.169.254. GitHub's troubleshooting page says that some Azure Identity SDKs read the EC2 answer as a failed Azure managed identity sign-in, and stop the credential chain there, before they try the Azure CLI session that azure/login set up. The step after a successful azure/login fails 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
If the application should use the Azure CLI session, pick that credential explicitly. For Go with the azidentity module 1.11.0 or later, set this on the application's step:
- name: Run application
env:
AZURE_TOKEN_CREDENTIALS: AzureCLICredential
run: ./application
In other languages, construct AzureCLICredential in the application, or configure environment or workload identity credentials, which come before managed identity in the chain. A successful azure/login does not by itself configure the SDK's workload identity credential.
An older image version
The AWS pool can run an older version of the same image. On October 31, a job on AWS ran ubuntu-26.04 20261018.50.1, while that night's Azure runners ran 20261025.179.1 (code-review #359). Another AWS job that day ran ubuntu-24.04 20261018.96.1, and the project's test jobs on Azure ran 20261025.353.1 (yshishenya/graf #7849, in Russian). The version is in Set up job, under "Runner Image". A tool that changed between the two versions can behave differently in two jobs of the same run.
A different apt source
On Azure, the Ubuntu images read packages through a mirror list: the image's build script replaces http://azure.archive.ubuntu.com/ubuntu/ in the apt sources with mirror+file:/etc/apt/apt-mirrors.txt, which lists the Azure mirror, then archive.ubuntu.com, then security.ubuntu.com. A check in one project that accepted that mirror list stopped the job with "unsupported Ubuntu mirror source" on AWS, and the project had not found out the AWS source yet (graf #7849). A script that rewrites /etc/apt/sources.list.d/ubuntu.sources by matching the Azure mirror or the mirror list may find nothing to change on AWS. Match any URI, or write the sources file in full.
Steps that need to start fast
On an AWS runner, the agent of the step-security/harden-runner action (v2.22.2) did not start within the 9.3 seconds the action waits. The action continues when that happens, so its block egress policy was never applied, and the project's own canary step caught it and failed the job (code-review #359). A step with a fixed wait for something on the machine can time out on one cloud and not the other.
Telling it apart
- The job fails with "Cloud: AWS" in Set up job and passes when a re-run shows "Cloud: Azure": one of the cases on this page.
- It fails the same way with "Cloud: Azure": not this. For apt that stops at
azure.archive.ubuntu.com, see apt slow or stuck on the Azure mirror. - The job never starts, and waits for a runner: not the cloud ("Waiting for a runner to pick up this job").
- Windows, macOS or a runner with Azure private networking: these stay where they were.
See failed jobs from IntelliJ IDEA
Pipeline Inbox for GitHub Actions Workflows, a plugin by Lesstep for JetBrains IDEs 2024.1 or later, lists the runs of all your repositories in an IDE tool window, with their jobs and steps, so a job that fails only now and then stands out, and your current branch's runs are in the status bar. Reading is free; re-running failed jobs, cancelling, running workflows and reviewing deployments are Pro (US$1.50 a month, with a 30-day trial).
Get it on JetBrains Marketplace
GitHub and GitHub Actions are trademarks of GitHub, Inc.; IntelliJ IDEA is a trademark of JetBrains s.r.o.; Amazon Web Services and AWS are trademarks of Amazon.com, Inc. or its affiliates; Microsoft, Azure and Microsoft Entra are trademarks of the Microsoft group of companies. This page is not affiliated with, sponsored or endorsed by any of them.
More: apt slow on the Azure mirror · "Waiting for a runner" · GitHub Actions plugins for IntelliJ IDEA compared · 日本語