La misma etiqueta de GitHub Actions ya puede ejecutarse en AWS
Un trabajo puede fallar al iniciar sesión en un servicio externo sin cambios en su YAML. GitHub anunció el 28 de octubre capacidad Linux en AWS además de Azure. La etiqueta puede seguir igual y la dirección de salida ser distinta.
Más capacidad detrás de las mismas etiquetas
Abarca runners Linux estándar de 2 y 4 núcleos y larger runners compatibles de esos tamaños sin configuraciones especiales. Excluye Windows y redes privadas. Free, Pro y Team participan automáticamente; Enterprise Cloud puede activar AWS en Actions > Hosted compute cloud providers.
GitHub distribuye trabajos elegibles entre proveedores disponibles sin modificar etiquetas ni sintaxis. Busca reducir esperas por capacidad y mejorar resiliencia. No garantiza que un trabajo concreto sea más rápido ni que se ejecute duplicado en dos nubes.
Por qué el fallo puede parecer intermitente
Imaginemos una API de despliegue que solo admite direcciones Azure. El mismo flujo podría pasar desde Azure y ser rechazado desde otra salida. GitHub menciona también Microsoft Entra Conditional Access. Es un ejemplo explicativo, no un incidente observado.
Antes de renovar tokens, compare hora, destino, IP de origen y política aplicada. Esperar capacidad y recibir un rechazo de autenticación después del arranque son etapas diferentes. Una cola más corta no corrige una regla de acceso.
Las IP se consultan como rangos
El punto de partida es actions en GET https://api.github.com/meta. La documentación REST pide consultar valores actuales, no copiar los ejemplos. Con Python ipaddress ejecutamos un ejemplo documental: 192.0.2.10 y 192.0.2.200 pertenecen a 192.0.2.0/24; 198.51.100.10 no. No son IP reales de runners.
Permitir todos los rangos no siempre conviene. La referencia desaconseja usar los numerosos rangos estándar para proteger recursos internos y propone larger runners con IP estática o runners propios. La red de origen tampoco sustituye autenticación y privilegios mínimos.
La etiqueta estable oculta una premisa nueva
Primero localice el fallo antes o después del inicio del trabajo; después contraste rangos actuales y políticas reales. Si necesita una salida fija, elija infraestructura preparada para ello. Una etiqueta de runner no identifica a un proveedor de nube.