AWX es el proyecto comunitario del que parte Ansible Automation Platform (AAP). AAP es el producto de Red Hat con suscripción, soporte y un ciclo de vida publicado. Si necesitas que alguien responda por la plataforma y fechas de soporte que puedas planificar, elige AAP. Si tu equipo puede mantener el servicio por su cuenta y acepta que no hay un proveedor detrás, AWX puede bastar. La decisión es sobre quién asume el riesgo, no sobre funciones.
Qué es cada uno
El README de AWX lo describe como "uno de los proyectos upstream" de Ansible Automation Platform: aporta la interfaz, la API y el motor de tareas para automatizar con Ansible. AAP añade un modelo de soporte comercial y una plataforma empresarial más amplia. El mismo README avisa de que la última versión del repositorio se publicó el 2 de julio de 2024 y de que las versiones están en pausa durante una refactorización a gran escala (consultado el 9 de octubre de 2026). Antes de adoptar AWX, comprueba en el repositorio si ese estado ha cambiado.
Las numeraciones tampoco coinciden: cuando se habla de pasar de la 2.4 a la 2.6, se habla de AAP, no de una actualización equivalente de AWX.
Comparativa
| Aspecto | AAP | AWX |
|---|---|---|
| Quién lo mantiene | Red Hat | Comunidad |
| Soporte | Suscripción con soporte de Red Hat, Standard (8x5) o Premium (24x7) | El README remite al foro de Ansible; no define una política de soporte |
| Ciclo de vida | Fases publicadas: Full Support, Maintenance Support 1 y 2, y soporte extendido opcional | No publica fechas de ciclo de vida |
| Versiones | Versiones con requisitos documentados (por ejemplo, la 2.6 por RPM exige RHEL 9) | Versiones del repositorio; las publicaciones están en pausa según su README |
| Coste | Suscripción | Sin licencia, pero con el coste de operarlo |
Fuentes de la tabla: la página de ciclo de vida de AAP, el artículo de Red Hat sobre qué incluye la suscripción y el README de AWX.
Qué cubre cada fase de AAP
Según la página de ciclo de vida de Red Hat, en Full Support hay correcciones de seguridad críticas, importantes y moderadas, además de errata de errores. En Maintenance Support 1 quedan las críticas e importantes, y solo errores críticos. En Maintenance Support 2 solo las críticas de seguridad. Existe además un soporte extendido opcional con correcciones de seguridad críticas cualificadas. Esas fases son lo que no tienes con AWX.
Cuándo AWX puede bastar
- Es un laboratorio, un entorno de pruebas o un uso interno donde una caída no duele.
- Tienes personas que saben operar y actualizar la plataforma y aceptan ese trabajo.
- No necesitas fechas de soporte de un proveedor.
Un ejemplo: recomendaría AWX a un laboratorio universitario que ejecuta automatización reproducible y no crítica. Si el equipo ya gestiona Kubernetes, sabe diagnosticar sus propios problemas y tolera interrupciones, AWX le da planificación y ejecución centralizada sin la suscripción de AAP. Aun así, su repositorio indica que las versiones están en pausa durante una refactorización, así que solo lo recomendaría donde esa incertidumbre de mantenimiento se acepte de forma explícita.
Cuándo elegir AAP
- Tu equipo necesita un proveedor al que reclamar cuando algo falla.
- Una auditoría o un cliente te pide versiones con soporte y fechas conocidas.
- La automatización toca sistemas críticos y no puedes depender de un proyecto con lanzamientos en pausa.
- Ya tienes suscripciones de Red Hat y el coste marginal es asumible.
Un ejemplo: recomendaría AAP a un banco que automatiza el parcheo de producción y cambios de red. El escalado al fabricante, los procedimientos de actualización con soporte y el contenido de automatización certificado justifican la suscripción cuando una caída afecta a clientes. La cobertura depende del nivel contratado: Standard es 8x5 y Premium es 24x7, según el artículo de Red Hat sobre la suscripción.
Cómo medir el esfuerzo de operación
Sin licencia no significa sin coste, y el esfuerzo de operar cada plataforma conviene medirlo, no suponerlo. Ejecuta cargas de trabajo comparables durante 90 días y anota las versiones, la infraestructura, el volumen de trabajos y la experiencia del equipo. Para cada plataforma, registra:
- Horas de administración al mes: mantenimiento, copias de seguridad, certificados, diagnóstico y actualizaciones.
- Incidencias de la plataforma al mes, clasificadas por gravedad.
- Tiempo de recuperación y minutos en que la automatización no estuvo disponible.
- Fallos causados por la plataforma por cada 1000 trabajos, separados de los errores de los playbooks.
- Pruebas de restauración superadas y horas dedicadas a casos de soporte.
Incluye el mantenimiento de Kubernetes que corresponde a AWX y el trabajo de infraestructura equivalente en AAP. El soporte puede acortar el diagnóstico, pero no elimina la administración. La documentación revisada no establece una cifra universal de horas al mes, así que compara juntos la suscripción, la infraestructura, el trabajo del equipo y el coste de las caídas.
Si actualizas AAP de 2.4 a 2.6
Según la guía de actualización de AAP 2.6, primero hay que estar en la última versión de 2.4. Red Hat admite la actualización directa en despliegues por RPM sobre RHEL 9 y en OpenShift. Una instalación por RPM sobre RHEL 8 exige antes copiarla y restaurarla en hosts nuevos con RHEL 9, porque no se admite actualizar el sistema operativo de versión mayor en el mismo host. Tampoco se admite actualizar desde el despliegue contenerizado de 2.4 que se publicó como Technology Preview.
En un despliegue por RPM que cumpla los requisitos, el flujo que documenta el procedimiento de actualización es, a grandes rasgos: copia de seguridad con el instalador existente (./setup.sh con la opción -b) y, después, ./setup.sh desde el instalador de la 2.6 con su inventario configurado, incluidos los requisitos de la pasarela de la plataforma. Esto ilustra el proceso; no es un procedimiento completo.
Un fallo documentado afecta a la autenticación SAML: las claves privadas cifradas impiden migrar los autenticadores, así que hay que sustituirlas siguiendo la guía de Red Hat antes de actualizar. Mide por separado la preparación, la copia, la instalación, la validación, la parada y la recuperación. Como referencia, la guía de actualización indica que migrar 4000 usuarios, 400 equipos y 40 organizaciones puede llevar cerca de dos horas; es un ejemplo, no una estimación de la actualización completa.
Actualizar compensa cuando los requisitos de soporte, las correcciones o las funciones que necesitas pesan más que el coste de una migración probada. Pasar de RPM a contenedores también prepara las siguientes versiones: según la misma guía, la 2.6 es la última versión para instalaciones por RPM. Ensaya primero, demuestra que la restauración funciona y valida la autenticación, los permisos, las integraciones y trabajos representativos antes del cambio en producción.
Si quieres un inventario de versiones, fechas de soporte y riesgos en tu entorno, la revisión de ciclo de vida de RHEL y AAP cubre justo eso.