Amazon Web Services (AWS) ha abierto la versión preliminar pública de Amazon Linux 2027 (AL2027), la próxima generación de su distribución para servidores y cargas cloud. El salto desde Amazon Linux 2023 trae cambios que afectan directamente al trabajo del administrador de sistemas: kernel Linux 7.1, SELinux en modo enforcing por defecto, DNF5, systemd 260, GCC 16.1, Python 3.14 y una renovación importante de la pila criptográfica. Todavía no es una versión para producción, pero ya permite empezar a probar migraciones, automatizaciones e imágenes propias.
Las claves de Amazon Linux 2027 para sysadmins en 30 segundos
- AL2027 está disponible como public preview para x86-64 y ARM64.
- El kernel predeterminado salta a Linux 7.1 y SELinux pasa de
permissiveaenforcing. - DNF5 sustituye a DNF4, RPM llega a la rama 6 y systemd sube a la versión 260.
- AWS actualiza también GCC, glibc, Python y buena parte del entorno de desarrollo.
- Antes de migrar conviene revisar políticas SELinux, scripts de administración, repositorios y software compilado internamente.
Para un administrador de sistemas, probablemente lo menos importante de Amazon Linux 2027 sea que tenga un número de kernel mayor que otras distribuciones. La pregunta útil es otra: qué puede dejar de funcionar cuando una instancia basada en Amazon Linux 2023 se reconstruya sobre AL2027.
Y ahí hay bastante que revisar.
Amazon Linux continúa siendo una distribución especialmente ligada a AWS. Utiliza paquetes RPM, DNF como gestor de paquetes y tecnologías habituales del entorno Linux empresarial, pero Amazon controla su ciclo de publicación, repositorios, kernels e integración con servicios propios.
AWS explica además que AL2027 incorpora componentes procedentes de Fedora 44 y Fedora 45, pero no debe considerarse una reconstrucción de una versión concreta de Fedora. Tampoco pretende ser compatible binariamente con Red Hat Enterprise Linux (RHEL), como ocurre con distribuciones orientadas específicamente a ese objetivo.
SELinux enforcing puede ser el cambio que más trabajo dé
El titular técnico es Linux 7.1, pero SELinux probablemente merezca más atención durante una migración real.
Amazon Linux 2023 utiliza SELinux en modo permissive de manera predeterminada. En esa configuración se registran las operaciones que incumplirían las políticas, pero el sistema no las bloquea.
Amazon Linux 2027 cambia el comportamiento predeterminado a:
SELinux status: enabled
Current mode: enforcingEsto significa que una aplicación interna, un servicio antiguo o una configuración creada durante años puede encontrarse con una denegación que antes solo terminaba registrada en los logs.
El cambio es positivo desde el punto de vista del endurecimiento del sistema, pero exige pruebas.
Antes de migrar una carga resulta razonable revisar los eventos generados actualmente por SELinux, especialmente en servidores con aplicaciones propias, directorios fuera de las rutas habituales, montajes NFS, servicios web personalizados o procesos que necesiten acceder a recursos con contextos diferentes.
Los administradores pueden comprobar el estado con:
sestatusy buscar denegaciones mediante herramientas como ausearch:
ausearch -m AVC,USER_AVC -ts recentPasar permanentemente a permissive para conseguir que una aplicación funcione puede ocultar el problema, pero también elimina buena parte de la protección que AWS pretende proporcionar con este cambio. Para producción tiene más sentido identificar la denegación y ajustar contextos o políticas cuando corresponda.
DNF5, RPM 6 y systemd 260 obligan a revisar automatizaciones
Amazon también renueva varias piezas que suelen quedar enterradas debajo de scripts de despliegue, imágenes y herramientas de configuración.
La comparación con Amazon Linux 2023 muestra el alcance del cambio:
| Componente | Amazon Linux 2023 | Amazon Linux 2027 Preview |
|---|---|---|
| Kernel predeterminado | 6.1 | 7.1 |
| SELinux | Permissive | Enforcing |
| DNF | 4.14 | DNF5 5.4 |
| RPM | 4.16 | 6.0 |
| systemd | 252 | 260 |
| GCC | 11.5 | 16.1 |
| glibc | 2.34 | 2.44 |
| LLVM/Clang | 15/18/19 | 22 |
| Python predeterminado | 3.9 | 3.14 |
| PCRE | PCRE1 y PCRE2 | PCRE2 |
| zlib | 1.2.11 | zlib-ng 2.3 |
DNF5 sustituye a DNF4 como implementación predeterminada. Los conocidos comandos:
dnfy
yumcontinúan disponibles, así que para una administración básica el cambio no debería resultar especialmente traumático.
El problema puede aparecer en automatizaciones que utilizan componentes internos de DNF. La API Python python3-dnf utilizada con DNF4 desaparece en AL2027 y las aplicaciones que dependan directamente de ella tendrán que adaptarse a python3-libdnf5.
Esto merece revisar scripts Python propios, herramientas internas y automatizaciones antiguas antes de asumir que una colección de Ansible, un bootstrap o un proceso de creación de imágenes funcionará sin modificaciones.
Algo parecido ocurre con systemd. AL2027 utiliza systemd 260 y deja atrás la compatibilidad con los antiguos scripts de inicio System V. Un servidor moderno probablemente ni siquiera los utilice, pero una aplicación empresarial instalada durante años puede esconder todavía algún init.d que nadie recuerda.
En una migración masiva es preferible descubrirlo en una AMI de laboratorio.
Python 3.14 y GCC 16.1: cuidado con el software propio
Otro punto especialmente relevante para administradores que mantienen aplicaciones internas es el salto del entorno de desarrollo.
Amazon Linux 2027 utiliza Python 3.14 como versión predeterminada, frente a Python 3.9 en AL2023. También pasa de GCC 11.5 a GCC 16.1 y de glibc 2.34 a glibc 2.44.
No significa automáticamente que las aplicaciones compiladas para AL2023 dejen de funcionar. AWS espera mantener un grado importante de compatibilidad para aplicaciones existentes.
Pero recompilar es otra historia.
GCC 16 incorpora cambios en estándares, comprobaciones y comportamientos predeterminados. Un proyecto que llevaba años compilando sin problemas puede empezar a generar avisos o errores que antes no aparecían.
Los scripts Python necesitan una revisión todavía más evidente. Un #!/usr/bin/python3 puede acabar ejecutándose con una versión muy diferente de la que tenía el servidor original.
Para aplicaciones Python resulta más seguro evitar depender innecesariamente del intérprete del sistema y utilizar entornos virtuales o mecanismos equivalentes:
python3 -m venv /opt/myapp/venv
source /opt/myapp/venv/bin/activateAL2027 también elimina PCRE1 y mantiene únicamente PCRE2, otro detalle que puede afectar a software antiguo compilado contra la primera biblioteca.
¿Amazon Linux, Ubuntu, Debian o Rocky para un servidor nuevo?
Amazon Linux 2027 tiene sentido principalmente cuando la infraestructura está estrechamente vinculada a AWS.
No existe una distribución universalmente mejor. Para un sysadmin importa mucho más el ciclo de vida, las aplicaciones que debe mantener y dónde va a ejecutarlas.
| Escenario | Distribución a considerar | Principal ventaja |
|---|---|---|
| Infraestructura casi exclusivamente AWS | Amazon Linux | Integración directa con AWS |
| EC2 sobre Graviton | Amazon Linux | ARM64 muy integrado en AWS |
| Inferentia/Trainium | Amazon Linux | AWS Neuron y aceleradores propios |
| Servidor Linux generalista | Debian | Estabilidad y portabilidad |
| Cloud/multicloud | Ubuntu LTS | Amplio soporte comercial y cloud |
| Entorno procedente de RHEL | Rocky/AlmaLinux | Compatibilidad con el entorno RHEL |
| On-premise + cloud | Debian/Ubuntu/Rocky/AlmaLinux | Menor vinculación a un proveedor |
| Contenedores sobre AWS | Amazon Linux | Imágenes oficiales y entorno AWS |
Hay una diferencia conceptual importante.
Un administrador puede instalar Debian, Ubuntu, Rocky Linux o AlmaLinux en prácticamente cualquier hipervisor, servidor físico o proveedor cloud y conservar una plataforma bastante parecida. Amazon Linux puede ejecutarse fuera de EC2 en determinados escenarios, pero su propuesta está claramente diseñada alrededor de AWS.
Eso puede ser una ventaja, no necesariamente un inconveniente.
En una empresa que utiliza EC2, Graviton, Auto Scaling, AWS Systems Manager, ECR y otros componentes de AWS, reducir diferencias entre el sistema operativo y la infraestructura puede simplificar operaciones.
Para una organización con AWS, Azure, infraestructura propia y varios proveedores de hosting, estandarizar sobre Ubuntu, Debian o una distribución de la familia RHEL puede ofrecer mayor homogeneidad.
Una comparación rápida para administradores
| Característica | AL2027 | Ubuntu 26.04 LTS | Debian 13 | Rocky/Alma 10 |
|---|---|---|---|---|
| Paquetes | RPM | DEB | DEB | RPM |
| Gestor | DNF5 | APT | APT | DNF |
| SELinux | Sí, enforcing | No por defecto | Disponible | Sí |
| AppArmor | No como principal | Sí | Disponible | No como principal |
| AWS optimizado | Sí | Sí, imágenes AWS | Imágenes AWS | Imágenes AWS |
| Multicloud | Posible | Muy habitual | Muy habitual | Muy habitual |
| Compatibilidad RHEL | No | No | No | Sí |
| ARM64 | Sí | Sí | Sí | Sí |
| AWS Neuron | Integración directa | Disponible según stack | Depende del entorno | Depende del entorno |
| Uso actual de AL2027 en producción | No recomendado aún | Sí | Sí | Sí |
La última fila es la más importante ahora mismo.
AL2027 continúa siendo una versión preliminar pública. AWS la proporciona para comprobar aplicaciones, generar imágenes de prueba, detectar incompatibilidades y comunicar problemas antes de la disponibilidad general.
No es el momento de sustituir indiscriminadamente las instancias AL2023 de producción.
Qué debería probar un sysadmin antes de plantearse AL2027
La preview sí ofrece una oportunidad para adelantarse. En organizaciones con decenas o centenares de instancias Amazon Linux, esperar a la disponibilidad general para descubrir incompatibilidades puede trasladar todo el trabajo al proyecto de migración.
Una primera AMI de laboratorio permite comprobar ya varios puntos:
- Arranque de la aplicación y servicios systemd.
- Denegaciones provocadas por SELinux
enforcing. - Scripts que dependan de Python 3.9.
- Automatizaciones relacionadas con DNF4.
- Paquetes RPM propios y repositorios internos.
- Software compilado contra glibc o PCRE antiguos.
- Agentes de monitorización, EDR y copias de seguridad.
- Módulos externos del kernel.
- Cloud-init y procesos de creación automática de instancias.
- Playbooks de Ansible, recetas y pipelines de generación de AMI.
También conviene probar el software de terceros. Que una aplicación funcione sobre una distribución RPM no significa que su fabricante vaya a certificar inmediatamente Amazon Linux 2027.
Para un administrador esa diferencia importa. Técnicamente puede funcionar y, al mismo tiempo, quedar fuera de la matriz de soporte del proveedor.
AWS ofrece las AMI preliminares de AL2027 en sus regiones comerciales, tanto para x86-64 como ARM64, además de imágenes base de contenedores mediante Amazon Elastic Container Registry (ECR) Public.
La integración con aceleradores también recibe atención. Amazon destaca la disponibilidad de drivers para AWS Neuron, el SDK utilizado con sus aceleradores Trainium e Inferentia para inteligencia artificial y aprendizaje automático.
El ciclo previsto de AL2027 llegará hasta 2032, aunque las condiciones correspondientes a esta versión preliminar son diferentes y AWS puede modificar componentes antes de la disponibilidad general.
Por eso la preview tiene más valor como banco de pruebas que como servidor nuevo. El kernel 7.1 atraerá buena parte de la atención, pero para quien tenga que administrar la plataforma probablemente sean SELinux enforcing, DNF5, systemd 260, Python 3.14 y los cambios de librerías los que determinen cuánto trabajo supondrá realmente pasar de AL2023 a AL2027.
