Durante años hemos mantenido en AWS Marketplace varias AMIs de Zabbix a la vez: la 4.2, la 4.4, la 6.0, la 6.4 y la 7.0. La idea era sencilla: hay equipos con instalaciones que, por integraciones, plantillas o simple prudencia, no pueden dar el salto a una versión mayor, y queríamos que tuvieran una imagen mantenida de la versión que usan.
Esa idea ya no es posible. De todo ese catálogo, en Marketplace solo queda nuestra AMI de Zabbix 7.0 LTS, y no por decisión nuestra: AWS Marketplace no acepta las demás. Te contamos por qué.
La regla: nada al final de su vida útil
AWS Marketplace revisa cada versión de una AMI antes de publicarla. Además de comprobar que la imagen arranca y cumple los requisitos técnicos, la analiza en busca de vulnerabilidades y de software sin soporte. La política es clara: no se admiten productos que usen un sistema operativo o un software que haya llegado al final de su vida útil (end of life, EOL).
Importan las dos mitades de la frase. No basta con que el sistema base esté soportado; también cuenta el software que la imagen lleva dentro. Y el criterio no es «está parcheado», sino «quien lo desarrolla lo sigue manteniendo».
Cómo lo aplica
En la práctica, el control llega por dos caminos:
- Al publicar una versión nueva. El escaneo de la imagen marca el sistema o el software EOL como hallazgo y la versión se rechaza. Da igual que el resto esté impecable: el hallazgo no se arregla reconstruyendo.
- Sobre el producto ya publicado. AWS puede pasar el producto a estado Restricted: deja de ofrecerse a nuevos compradores y no admite versiones nuevas. Quien ya tenía la suscripción conserva el acceso a sus instancias, pero el producto queda congelado.
Las dos cosas van juntas. Un producto restringido no puede recibir una versión que lo saque de ahí, y cualquier versión que se construya sobre la misma base va a chocar con el mismo escaneo.
Dos calendarios que tienen que cuadrar
Una AMI de Zabbix depende de dos ciclos de vida a la vez, y los dos tienen que estar dentro de soporte:
- El de Zabbix. Las versiones standard (4.2, 4.4, 6.4…) se mantienen solo unos meses, hasta que sale la siguiente. Las LTS (6.0, 7.0…) tienen varios años de soporte, pero también caducan.
- El de Ubuntu. Cada versión de Zabbix solo publica paquetes para las releases de Ubuntu que existían mientras se desarrollaba. Una versión antigua de Zabbix no llega a las Ubuntu nuevas, así que queda atada a un sistema que acabará saliendo de soporte.
Con esos dos calendarios, así queda cada una de nuestras AMIs antiguas:
| AMI | Zabbix | Ubuntu | Por qué no pasa |
|---|---|---|---|
| Zabbix 4.2 | standard, sin mantenimiento desde 2019 | 18.04, sin soporte estándar desde 2023 | Zabbix y sistema EOL. 4.2 no tiene paquetes para ninguna Ubuntu posterior a 18.04 |
| Zabbix 4.4 | standard, sin mantenimiento | 18.04, sin soporte estándar desde 2023 | Zabbix y sistema EOL. 4.4 llega como mucho a Ubuntu 20.04, que también está fuera de soporte |
| Zabbix 6.0 | LTS | 20.04, sin soporte estándar desde 2025 | El sistema base está EOL |
| Zabbix 6.4 | standard, sin mantenimiento | 22.04 | La propia versión de Zabbix está EOL |
La conclusión es incómoda pero clara: la única línea que cumple la política de forma sostenida es la última LTS de Zabbix sobre una Ubuntu LTS con soporte. Hoy eso es Zabbix 7.0 sobre Ubuntu 24.04. Mantener más líneas en Marketplace significa mantener productos que AWS va a retirar en cuanto el siguiente calendario caduque.
El caso que lo destapó: Zabbix 4.2
Nos dimos cuenta al preparar la última versión de la AMI de Zabbix 4.2. El escaneo de AWS devolvió tres hallazgos: uso de software al final de su vida útil (Ubuntu 18.04) y dos CVE, CVE-2023-4863 en libwebp y CVE-2023-44487 en nghttp2.
¿Y si se parchea?
Es la primera pregunta, y la respuesta es que no sirve. Los parches de esos dos CVE para Ubuntu 18.04 solo existen en ESM, es decir, en Ubuntu Pro. Aunque los aplicásemos, el hallazgo principal seguiría ahí: el soporte extendido de pago no convierte en soportada una release que ha salido del soporte estándar.
¿Y si se cambia de sistema?
Tampoco. El repositorio oficial de Zabbix 4.2 solo publica paquetes hasta Ubuntu 18.04. Probamos también la vía de Debian y acaba en el mismo sitio: el último Debian con paquetes de 4.2 está fuera de soporte, y en los actuales ni los paquetes instalan ni el código compila sin reescribir medio frontend. Y aunque lo consiguiéramos, seguiría siendo Zabbix 4.2, que es software EOL por sí mismo.
El mismo razonamiento, con matices, se aplica al resto de la tabla. Por eso hemos retirado la ficha de Zabbix 4.2 y en Marketplace dejamos solo la 7.0.
Qué significa para ti
- Si ya tienes una instancia con una versión antigua, sigue funcionando exactamente igual. Nada se apaga. Lo que no va a haber son versiones nuevas en Marketplace.
- Si puedes actualizar, la vía recomendada es nuestra AMI de Zabbix 7.0 LTS, sobre Ubuntu 24.04. En la ficha tienes la guía de migración para llevarte la base de datos sin perder histórico.
- Si necesitas seguir en una versión anterior, podemos preparar una versión a medida para tu cuenta de AWS, fuera de Marketplace, con el mismo autoescalado y las mismas notificaciones por SNS. Escríbenos a soporte y lo vemos.
Una lección que va más allá de Zabbix
Lo que le ha pasado a nuestro catálogo de Zabbix le pasará, tarde o temprano, a cualquier imagen que dependa de una release concreta. Por eso nuestras AMIs instalan cada pieza desde el repositorio oficial de su proyecto y siguen líneas con soporte, y por eso revisamos el calendario de cada producto antes de que lo haga AWS: cuando el sistema o el software se acercan a su fin de vida, la migración tiene que estar hecha antes de que el escaneo lo diga.
