Jahrelang hatten wir mehrere Zabbix-AMIs gleichzeitig im AWS Marketplace: 4.2, 4.4, 6.0, 6.4 und 7.0. Die Idee war einfach: Manche Teams betreiben Installationen, die wegen Integrationen, Vorlagen oder schlicht aus Vorsicht nicht auf eine neue Hauptversion wechseln können – und sie sollten ein gepflegtes Image genau ihrer Version haben.
Das ist nicht mehr möglich. Von diesem ganzen Katalog ist im Marketplace nur noch unsere AMI für Zabbix 7.0 LTS übrig, und das war nicht unsere Entscheidung: AWS Marketplace akzeptiert die anderen nicht. Hier erklären wir, warum.
Die Regel: nichts am Ende des Lebenszyklus
AWS Marketplace prüft jede Version einer AMI vor der Veröffentlichung. Neben der Kontrolle, ob das Image startet und die technischen Anforderungen erfüllt, wird es auf Schwachstellen und Software ohne Support gescannt. Die Richtlinie ist eindeutig: Produkte, deren Betriebssystem oder Software das Ende des Lebenszyklus (End of Life, EOL) erreicht hat, werden nicht akzeptiert.
Beide Hälften des Satzes zählen. Es reicht nicht, dass das Basissystem unterstützt wird; auch die Software im Image zählt. Und das Kriterium ist nicht „ist gepatcht“, sondern „wird von den Entwicklern noch gepflegt“.
Wie das durchgesetzt wird
In der Praxis kommt die Prüfung auf zwei Wegen:
- Beim Veröffentlichen einer neuen Version. Der Scan meldet das EOL-System oder die EOL-Software als Befund, und die Version wird abgelehnt. Wie sauber der Rest ist, spielt keine Rolle: Durch Neubauen verschwindet der Befund nicht.
- Bei einem bereits veröffentlichten Produkt. AWS kann das Produkt in den Status Restricted versetzen: Es wird neuen Käufern nicht mehr angeboten und nimmt keine neuen Versionen an. Bestehende Abonnenten behalten den Zugriff auf ihre Instanzen, aber das Produkt ist eingefroren.
Beides hängt zusammen. Ein eingeschränktes Produkt kann keine Version erhalten, die es aus diesem Zustand holt, und jede Version auf derselben Basis scheitert am selben Scan.
Zwei Kalender, die zusammenpassen müssen
Eine Zabbix-AMI hängt von zwei Lebenszyklen gleichzeitig ab, und beide müssen im Support liegen:
- Der von Zabbix. Standard-Versionen (4.2, 4.4, 6.4 …) werden nur wenige Monate gepflegt, bis die nächste erscheint. LTS-Versionen (6.0, 7.0 …) haben mehrere Jahre Support, laufen aber ebenfalls aus.
- Der von Ubuntu. Jede Zabbix-Version veröffentlicht nur Pakete für die Ubuntu-Releases, die während ihrer Entwicklung existierten. Eine alte Zabbix-Version erreicht neue Ubuntu-Releases nie und bleibt an ein System gebunden, das irgendwann aus dem Support fällt.
Mit diesen beiden Kalendern stehen unsere alten AMIs so da:
| AMI | Zabbix | Ubuntu | Warum sie scheitert |
|---|---|---|---|
| Zabbix 4.2 | Standard, seit 2019 nicht gepflegt | 18.04, seit 2023 ohne Standard-Support | Zabbix und System EOL. Für 4.2 gibt es keine Pakete nach Ubuntu 18.04 |
| Zabbix 4.4 | Standard, nicht gepflegt | 18.04, seit 2023 ohne Standard-Support | Zabbix und System EOL. 4.4 reicht nur bis Ubuntu 20.04, das ebenfalls keinen Support mehr hat |
| Zabbix 6.0 | LTS | 20.04, seit 2025 ohne Standard-Support | Das Basissystem ist EOL |
| Zabbix 6.4 | Standard, nicht gepflegt | 22.04 | Die Zabbix-Version selbst ist EOL |
Die Schlussfolgerung ist unbequem, aber klar: Die einzige Linie, die die Richtlinie dauerhaft erfüllt, ist die neueste Zabbix-LTS auf einer unterstützten Ubuntu-LTS. Heute ist das Zabbix 7.0 auf Ubuntu 24.04. Mehr Linien im Marketplace zu pflegen hieße, Produkte zu pflegen, die AWS zurückzieht, sobald der nächste Kalender abläuft.
Der Fall, der es aufgedeckt hat: Zabbix 4.2
Aufgefallen ist es uns bei der Vorbereitung der letzten Version der AMI für Zabbix 4.2. Der AWS-Scan lieferte drei Befunde: Einsatz von Software am Ende des Lebenszyklus (Ubuntu 18.04) und zwei CVEs, CVE-2023-4863 in libwebp und CVE-2023-44487 in nghttp2.
Und wenn man patcht?
Das ist die erste Frage, und die Antwort lautet: Es hilft nicht. Die Patches für diese beiden CVEs unter Ubuntu 18.04 gibt es nur in ESM, also in Ubuntu Pro. Selbst wenn wir sie einspielten, bliebe der Hauptbefund bestehen: Kostenpflichtiger erweiterter Support macht aus einem Release ohne Standard-Support kein unterstütztes Release.
Und wenn man das System wechselt?
Auch nicht. Das offizielle Repository von Zabbix 4.2 veröffentlicht Pakete nur bis Ubuntu 18.04. Wir haben auch den Weg über Debian geprüft, mit demselben Ergebnis: Das letzte Debian mit 4.2-Paketen hat keinen Support mehr, und auf aktuellen Releases lassen sich die Pakete nicht installieren und der Code nicht kompilieren, ohne das halbe Frontend umzuschreiben. Und selbst dann bliebe es Zabbix 4.2 – für sich genommen EOL-Software.
Dieselbe Überlegung gilt, mit Abstufungen, für den Rest der Tabelle. Deshalb haben wir die Seite für Zabbix 4.2 entfernt und behalten im Marketplace nur 7.0.
Was das für Sie bedeutet
- Wenn Sie bereits eine Instanz mit einer alten Version betreiben, läuft sie genau wie bisher weiter. Nichts wird abgeschaltet. Neue Versionen im Marketplace wird es aber nicht geben.
- Wenn Sie aktualisieren können, empfehlen wir unsere AMI für Zabbix 7.0 LTS auf Ubuntu 24.04. Auf der Seite finden Sie die Migrationsanleitung, mit der Sie Ihre Datenbank ohne Verlust der Historie übernehmen.
- Wenn Sie bei einer älteren Version bleiben müssen, erstellen wir Ihnen eine individuelle Version für Ihr AWS-Konto, außerhalb des Marketplace, mit derselben Autoskalierung und denselben SNS-Benachrichtigungen. Schreiben Sie unserem Support.
Eine Lehre über Zabbix hinaus
Was unserem Zabbix-Katalog passiert ist, passiert früher oder später jedem Image, das an ein bestimmtes Release gebunden ist. Deshalb installieren unsere AMIs jede Komponente aus dem offiziellen Repository ihres Projekts und folgen Linien mit Support, und deshalb prüfen wir den Kalender jedes Produkts, bevor AWS es tut: Wenn System oder Software sich dem Lebensende nähern, muss die Migration erledigt sein, bevor der Scan es meldet.
