Actualizado: 2 de noviembre de 2026. GitHub Actions está ampliando la infraestructura de sus runners hospedados: los jobs Linux elegibles podrán ejecutarse en Amazon Web Services (AWS), además de Microsoft Azure. El objetivo es mejorar capacidad, tiempos de cola y resiliencia, pero el cambio tiene una consecuencia inmediata para arquitectos de nube: las allowlists basadas únicamente en rangos de Azure o Microsoft pueden bloquear conexiones desde los nuevos runners.
Qué cambió
Desde el 28 de octubre de 2026, GitHub puede programar jobs elegibles sobre un pool multicloud. La expansión cubre runners Linux estándar de 2 y 4 cores y runners Linux “larger” compatibles de 2 y 4 cores sin configuraciones especializadas. Las etiquetas existentes y la sintaxis de los workflows no cambian.
- GitHub Free, Pro y Team: el uso de cómputo multicloud se habilita automáticamente para runners elegibles.
- GitHub Enterprise Cloud: el administrador empresarial debe habilitar AWS en Enterprise settings → Actions → Hosted compute cloud providers.
- No incluidos: runners Windows, runners con private networking y otras configuraciones especializadas.
Por qué puede romper pipelines
Un workflow puede mantener exactamente el mismo YAML y, sin embargo, salir a Internet desde una dirección IP diferente. Si un Key Vault, Storage Account, API, firewall, proxy o plataforma SaaS acepta solamente rangos asociados a Azure, el job podría empezar a fallar de forma intermitente cuando GitHub lo ejecute en AWS.
GitHub advierte además que las políticas de acceso basadas en red —incluidas políticas de Microsoft Entra Conditional Access que dependan de ubicaciones con nombre— pueden rechazar autenticaciones originadas desde esos runners. El patrón de fallo puede parecer aleatorio porque el scheduler selecciona el proveedor disponible.
Qué debe revisar un arquitecto
- Inventariar dependencias de red: identificar workflows que acceden a endpoints restringidos por IP, firewalls, proxies o ubicaciones de confianza.
- Consultar la fuente correcta: usar el array
actionsdel endpointGET https://api.github.com/meta. No mantener una lista estática de rangos de Azure. - Automatizar la sincronización: comparar periódicamente los rangos publicados con las reglas efectivas y generar una aprobación antes de aplicar cambios en firewalls sensibles.
- Revisar Conditional Access: comprobar si los flujos no interactivos dependen de named locations. Cuando sea posible, preferir identidad de workload, tokens de corta duración y autorización por recurso sobre confianza por IP.
- Probar antes de habilitar en Enterprise: usar una organización piloto, validar autenticación, acceso a registries, artefactos, secretos y destinos de despliegue.
Patrón arquitectónico recomendado
Las direcciones IP de runners hospedados son un control operativo, no una identidad. Para despliegues en Azure, el diseño preferido es OpenID Connect con federación de identidad de workload, permisos RBAC mínimos y credenciales efímeras. Las allowlists siguen siendo necesarias en algunos escenarios, pero no deberían ser el único control de confianza.
Cuando el destino exige conectividad privada o rangos de salida deterministas, utiliza runners con private networking o runners autohospedados dentro de un segmento controlado. Esa decisión aumenta la responsabilidad operativa: parcheo, aislamiento, limpieza del workspace, escalado y protección frente a código de pull requests.
Lista de acción inmediata
- Buscar reglas que permitan únicamente rangos de Microsoft o Azure para tráfico de GitHub Actions.
- Validar que las reglas consuman todos los rangos del array
actionsde GitHub Meta API. - Revisar named locations de Entra usadas por pipelines.
- Ejecutar un workflow de prueba contra cada destino protegido y registrar la IP de salida.
- Documentar un rollback antes de habilitar AWS compute en GitHub Enterprise Cloud.
Relación con Agentic DevOps
La infraestructura de ejecución se vuelve todavía más importante cuando los workflows incorporan agentes y automatizaciones con mayor autonomía. Para ampliar ese contexto, consulta Microsoft AZ-401: conoce la nueva certificación Agentic DevOps Engineer Expert.
Referencias oficiales
- GitHub Actions adds multi-cloud compute to improve reliability — 28 de octubre de 2026.
- GitHub Meta API.
- GitHub-hosted runners reference.
Propuesta para LinkedIn
GitHub Actions ya puede ejecutar jobs Linux elegibles en AWS además de Azure. La sintaxis no cambia, pero tus allowlists, firewalls y named locations de Microsoft Entra sí pueden necesitar ajustes. En este artículo explico qué cargas están afectadas, por qué confiar solo en IP no es suficiente y cómo preparar una transición segura con Meta API, OIDC y pruebas controladas. #GitHubActions #AzureDevOps #CloudSecurity #MicrosoftEntra #DevSecOps