Amazon Web Services abrió el 3 de septiembre de 2026 la vista previa pública de Amazon Linux 2027 (AL2027), la siguiente generación de su distribución para EC2 y contenedores. La primera build se llama 2027.0.20260903 y AWS lo deja claro en cada página de la documentación: es para evaluar y probar, no para cargas de producción. Hay AMI en todas las regiones comerciales, para x86-64 y ARM64, e imágenes base de contenedor en ECR Public.
El titular es el kernel Linux 7.1, pero para quien administra máquinas lo que va a dar trabajo está en otra parte: SELinux pasa de permissive a enforcing, DNF5 sustituye a DNF4, RPM salta a la rama 6, systemd sube a la 260 y desaparecen piezas de las que dependen scripts viejos. Si tienes flotas en Amazon Linux 2023, la vista previa sirve justo para descubrir eso ahora y no cuando llegue la versión final.
Qué cambia respecto a AL2023
La documentación de AWS publica la comparación pieza a pieza. Esta es la parte que importa:
| Componente | Amazon Linux 2023 | Amazon Linux 2027 (preview) |
|---|---|---|
| Kernel por defecto | 6.1 (con 6.12 y 6.18 opcionales) | 7.1 (paquete kernel7.1) |
| SELinux | Permissive | Enforcing |
| DNF | 4.14 | DNF5 5.4 |
| RPM | 4.16 | 6.0 (firmas con rpm-sequoia) |
| systemd | 252 | 260, sin scripts System V |
| GCC | 11.5 | 16.1 |
| glibc | 2.34 | 2.44 |
| binutils | 2.41 | 2.46 |
| LLVM/Clang | 15, 18 y 19 | 22 (un solo SRPM) |
| Python por defecto | 3.9 | 3.14 |
| zlib | 1.2.11 | zlib-ng 2.3 |
| PCRE | PCRE 8.x y PCRE2 | Solo PCRE2 |
Los paquetes de kernel llevan la versión en el nombre, como ya pasaba en AL2023, y AWS irá añadiendo kernels más nuevos con el tiempo. Según Phoronix, además, los paquetes de x86-64 se compilan ahora para el nivel x86-64-v3 (da por hecho AVX y AVX2) y con LTO activado, así que no cuentes con arrancar AL2027 en hardware x86 muy antiguo.
AL2027 se basa en parte en Fedora 44 y 45, pero AWS insiste en que no es un derivado ni una reconstrucción de una Fedora concreta, y en que el kernel se elige directamente de kernel.org sin mirar lo que lleva Fedora. Tampoco busca compatibilidad binaria con RHEL, que es el terreno de Rocky y AlmaLinux.
SELinux en enforcing es lo primero que hay que probar
En AL2023 SELinux venía en permissive: registraba lo que habría bloqueado, pero no bloqueaba nada. En AL2027 el valor por defecto es enforcing, y las aplicaciones principales de la distribución llegan con política preconfigurada.
Eso significa que una aplicación interna que lleva años funcionando, un servicio que escribe en un directorio poco habitual, un montaje NFS o un proceso que lee ficheros con el contexto equivocado se van a encontrar con una denegación real donde antes solo había una línea en el log. Es un cambio bueno para el endurecimiento del sistema, pero exige pasar por él antes de migrar nada.
Lo razonable es mirar hoy, en las máquinas AL2023 que ya tienes, qué está dejando SELinux en los registros:
sestatus
ausearch -m AVC,USER_AVC -ts recentTodo lo que aparezca ahí como aviso será un bloqueo en AL2027. Pasar el sistema entero a permissive para que una aplicación arranque tapa el problema y tira a la basura la protección que AWS quiere dar con este cambio; lo que toca es ajustar contextos o políticas caso por caso.
DNF5, RPM 6 y systemd 260: revisa lo que tienes automatizado
Los comandos dnf y yum siguen existiendo y ejecutan DNF5 por debajo, así que para administrar a mano no cambia mucho. El problema está en lo que usa DNF desde Python: la API python3-dnf de DNF4 no está en AL2027 y hay que pasar a python3-libdnf5. Cualquier script propio, colección de Ansible o proceso de creación de imágenes que la toque va a fallar.
RPM 6.0 verifica las firmas OpenPGP con la implementación rpm-sequoia. Si mantienes ficheros spec propios o repositorios internos, prueba que se construyen y se firman igual.
Con systemd 260 se acaba la compatibilidad con los scripts de servicio System V. Un servidor montado hace poco no los usa, pero una aplicación empresarial instalada hace años puede esconder todavía algún init.d que nadie recuerda, y eso es mejor encontrarlo en una AMI de laboratorio.
Python 3.14, GCC 16 y lo que compilas tú
El intérprete python3 del sistema pasa de 3.9 a 3.14. AWS dice que lo compilado en AL2023 en general funciona en AL2027, pero recompilar es otra historia: GCC 16 tiene valores por defecto más estrictos y un proyecto que llevaba años compilando limpio puede empezar a soltar avisos y errores. Lo mismo con lo enlazado contra PCRE1, que ya no existe, o contra la zlib clásica, que ahora es zlib-ng a través del paquete zlib-ng-compat.
Para el software propio en Python, la recomendación de siempre vale más que nunca: no dependas del intérprete del sistema y usa un entorno virtual.
python3 -m venv /opt/miapp/venv
source /opt/miapp/venv/bin/activateHay un detalle nuevo que afecta a los despliegues: AL2027 activa por defecto el periodo de enfriamiento de dependencias para npm y pip. Retrasa la instalación de paquetes recién publicados para dar tiempo a detectar los maliciosos antes de que lleguen a tus máquinas. En AL2023 existía desde finales de 2023, pero había que configurarlo a mano.
AWS-LC junto a OpenSSL
AL2027 añade AWS-LC, la librería criptográfica de AWS derivada de BoringSSL y OpenSSL, con partes verificadas formalmente y criptografía validada FIPS 140. No sustituye a OpenSSL: OpenSSL 3.5 sigue siendo la librería del sistema y la mayoría de paquetes enlazan contra ella. Pero en la vista previa ya hay una lista que va a crecer de paquetes compilados contra AWS-LC en su lugar, entre ellos httpd, haproxy, rsync, socat, wget1, libpq, python3.14, python-cryptography y las herramientas TPM2. Para nginx hay un paquete aparte, nginx-awslc.
Las dos librerías no cubren exactamente lo mismo en ambas direcciones, así que si tienes software que se apoya en funciones concretas de OpenSSL, mira en qué paquete acaba enlazado.
Fechas y qué hacer con AL2023
AWS dice que AL2027 tendrá soporte hasta 2032, con el mismo modelo que AL2023: una fase estándar con versiones menores trimestrales y una de mantenimiento solo con seguridad y correcciones críticas. Durante la vista previa, dnf supportinfo solo enseña fechas hasta el fin del periodo de pruebas; las reales llegarán con la disponibilidad general.
No hay prisa por el otro lado. Según los datos de la ficha de Amazon Linux, AL2023 sigue con soporte hasta 2029. Quien todavía tenga instancias en Amazon Linux 2, en cambio, ya va tarde: su ciclo terminó el 30 de junio de 2026.
Lo que sí tiene sentido hacer ahora, con una AMI de prueba, es una lista corta: arranque de servicios, denegaciones de SELinux, scripts atados a Python 3.9 o a la API de DNF4, paquetes RPM propios, software enlazado contra glibc o PCRE antiguos, agentes de monitorización y de copias, módulos externos de kernel, cloud-init y los pipelines que generan tus AMI. Y comprobar con cada fabricante de software de terceros si va a certificar AL2027, porque que funcione no significa que esté dentro de su matriz de soporte.
Si tu infraestructura no vive en AWS, esta versión te importa poco. Amazon Linux está diseñada alrededor de EC2, Graviton, ECR y compañía, y su ventaja es justo esa integración (incluidos los drivers de AWS Neuron para Trainium e Inferentia). Para un servidor generalista o para trabajar con varios proveedores, Debian, Ubuntu LTS o la familia RHEL siguen dando una plataforma más parecida en cualquier sitio.
Fuentes: anuncio de la vista previa de Amazon Linux 2027, comparativa AL2023 / AL2027, cadencia de versiones y relación con Fedora en la documentación de AWS; repositorio amazon-linux-2027 en GitHub; Amazon Linux 2027 Now in Preview, en Phoronix; Amazon Linux 2027 llega con kernel 7.1: qué cambia para los administradores, en Administración de Sistemas.