GitHub Actions ergänzt Multi-Cloud-Rechenleistung: Linux-Jobs können auf AWS laufen, IP-Allowlists anpassen

GitHub hat am 28. Oktober 2026 mitgeteilt, dass GitHub Actions geeignete Jobs nun auf einen breiteren Multi-Cloud-Rechenpool verteilt; geeignete Linux-Jobs können also zusätzlich zu Microsoft Azure auch auf Amazon Web Services laufen. Die genannten Ziele sind mehr Kapazität, kürzere kapazitätsbedingte Wartezeiten und bessere Ausfallsicherheit bei Spitzenlast. Die Änderung wird schrittweise ausgerollt und kommt mit einer Warnung: Netzwerk-Allowlists, die nur Azure- oder Microsoft-Bereiche nennen, können die neuen Runner blockieren.

Der Geltungsbereich ist eng. Multi-Cloud-Rechenleistung gilt für Standard-Linux-Runner mit 2 und 4 Kernen sowie für kompatible größere Runner mit 2 und 4 Kernen ohne Spezialkonfiguration. Sie gilt nicht für Windows-Runner und nicht für Runner mit privatem Netzwerk oder anderer Spezialkonfiguration. GitHub nennt weder den Anteil der Jobs, die wechseln, noch einen Starttermin je Konto noch eine gemessene Verbesserung der Wartezeit; der Nutzen ist daher ein erklärtes Ziel, kein Ergebnis.

Wer es bekommt, hängt vom Tarif ab. Kunden von GitHub Free, Pro und Team nutzen die Multi-Cloud-Rechenleistung für geeignete Runner automatisch. Kunden von GitHub Enterprise Cloud müssen zustimmen: In den Enterprise-Einstellungen unter Actions, bei den Anbietern für gehostete Rechenleistung, aktiviert ein Administrator AWS-Rechenleistung. GitHub sagt, geeignete Jobs würden automatisch auf die verfügbaren Anbieter verteilt, Runner-Labels und Workflow-Syntax blieben gleich. Ein Team wählt also nicht je Job eine Cloud; es entscheidet bei Enterprise Cloud nur, ob AWS-Rechenleistung überhaupt erlaubt ist.

Die empfohlene Maßnahme ist der Teil, der Pipelines brechen kann. Runner im erweiterten Pool nutzen zusätzliche ausgehende IP-Adressen. Eine Richtlinie, die nur Azure- oder Microsoft-eigene Bereiche zulässt, einschließlich einer Microsoft-Entra-Richtlinie für bedingten Zugriff, kann daher Verbindungen oder Authentifizierung dieser Runner blockieren. Wahrscheinlich betroffen sind Jobs, die eine durch Firewall geschützte Datenbank, eine private Paketregistry oder eine Cloud-API erreichen, die die Adresse des Aufrufers prüft. Weil der Rollout schrittweise erfolgt, könnte ein solcher Fehler nur zeitweise und bei einzelnen Jobs auftreten, was die Diagnose erschwert.

GitHubs Lösung ist, keine cloudspezifischen Listen mehr zu pflegen. Alle IP-Bereiche der GitHub-Actions-Runner, auch die neuen, stehen im Array actions in der Antwort von GET https://api.github.com/meta. GitHub empfiehlt, Allowlists mit diesem Endpunkt abzugleichen statt sich auf Bereiche eines Cloud-Anbieters zu verlassen, und das jetzt zu tun, bevor Workflows im erweiterten Pool laufen. Ein Team kann den Abgleich skripten und regelmäßig ausführen, da sich die veröffentlichte Liste ändern kann. Enterprise-Cloud-Kunden, die nicht zustimmen, vermeiden die neuen Adressen, doch der Eintrag sagt nicht, wie lange diese Wahl bestehen bleibt.

Für die meisten Teams ist die Arbeit klein und konkret: jede Firewall-Regel, jede Richtlinie für bedingten Zugriff und jede Cloud-Sicherheitsgruppe finden, die GitHub-gehostete Runner zulässt, feste Bereiche durch die Liste des meta-Endpunkts ersetzen und nach Beginn des Rollouts die Protokolle auf blockierte Verbindungen prüfen. Teams mit Windows-Runnern, größeren Spezial-Runnern oder privatem Netzwerk können festhalten, dass diese außerhalb der Ankündigung liegen.