For years we kept several Zabbix AMIs on AWS Marketplace at the same time: 4.2, 4.4, 6.0, 6.4 and 7.0. The idea was simple: some teams run installations that, because of integrations, templates or plain caution, cannot jump to a new major version, and we wanted them to have a maintained image of the version they use.
That idea is no longer possible. Of that whole catalogue, only our Zabbix 7.0 LTS AMI remains on Marketplace, and not by our choice: AWS Marketplace does not accept the others. Here is why.
The rule: nothing at end of life
AWS Marketplace reviews every version of an AMI before publishing it. Besides checking that the image boots and meets the technical requirements, it scans it for vulnerabilities and unsupported software. The policy is clear: products that use an operating system or software that has reached end of life (EOL) are not accepted.
Both halves of that sentence matter. It is not enough for the base system to be supported; the software inside the image counts too. And the test is not “is it patched” but “is it still maintained by the people who build it”.
How it is enforced
In practice, the check arrives in two ways:
- When publishing a new version. The image scan flags the EOL system or software as a finding and the version is rejected. It does not matter how clean the rest is: the finding does not go away by rebuilding.
- On a product already published. AWS can move the product to the Restricted state: it is no longer offered to new buyers and accepts no new versions. Existing subscribers keep access to their instances, but the product is frozen.
The two go hand in hand. A restricted product cannot receive a version that gets it out of that state, and any version built on the same base will hit the same scan.
Two calendars that have to line up
A Zabbix AMI depends on two lifecycles at once, and both have to be within support:
- Zabbix’s. Standard releases (4.2, 4.4, 6.4…) are only maintained for a few months, until the next one ships. LTS releases (6.0, 7.0…) get several years of support, but they expire too.
- Ubuntu’s. Each Zabbix version only publishes packages for the Ubuntu releases that existed while it was being developed. An old Zabbix version never reaches newer Ubuntu releases, so it stays tied to a system that will eventually fall out of support.
With those two calendars, this is where each of our old AMIs stands:
| AMI | Zabbix | Ubuntu | Why it fails |
|---|---|---|---|
| Zabbix 4.2 | standard, unmaintained since 2019 | 18.04, out of standard support since 2023 | Zabbix and system EOL. 4.2 has no packages for any Ubuntu after 18.04 |
| Zabbix 4.4 | standard, unmaintained | 18.04, out of standard support since 2023 | Zabbix and system EOL. 4.4 only reaches Ubuntu 20.04, which is also out of support |
| Zabbix 6.0 | LTS | 20.04, out of standard support since 2025 | The base system is EOL |
| Zabbix 6.4 | standard, unmaintained | 22.04 | The Zabbix version itself is EOL |
The conclusion is uncomfortable but clear: the only line that meets the policy over time is the latest Zabbix LTS on a supported Ubuntu LTS. Today that is Zabbix 7.0 on Ubuntu 24.04. Keeping more lines on Marketplace means keeping products that AWS will withdraw as soon as the next calendar runs out.
The case that exposed it: Zabbix 4.2
We noticed while preparing the latest version of the Zabbix 4.2 AMI. The AWS scan returned three findings: use of end-of-life software (Ubuntu 18.04) and two CVEs, CVE-2023-4863 in libwebp and CVE-2023-44487 in nghttp2.
What about patching it?
That is the first question, and the answer is that it does not help. The fixes for those two CVEs on Ubuntu 18.04 only exist in ESM, that is, in Ubuntu Pro. Even if we applied them, the main finding would still be there: paid extended support does not turn a release that has left standard support into a supported one.
What about changing the system?
No luck either. The official Zabbix 4.2 repository only publishes packages up to Ubuntu 18.04. We also tried the Debian route and it ends in the same place: the last Debian with 4.2 packages is out of support, and on current releases the packages do not install and the code does not compile without rewriting half the frontend. And even if we managed it, it would still be Zabbix 4.2, which is EOL software in its own right.
The same reasoning, with nuances, applies to the rest of the table. That is why we have removed the Zabbix 4.2 page and keep only 7.0 on Marketplace.
What it means for you
- If you already run an instance with an old version, it keeps working exactly as before. Nothing gets switched off. What there will not be is new versions on Marketplace.
- If you can upgrade, the recommended path is our Zabbix 7.0 LTS AMI, on Ubuntu 24.04. Its page includes the migration guide to bring your database over without losing history.
- If you need to stay on an earlier version, we can build a custom version for your AWS account, outside Marketplace, with the same autoscaling and the same SNS notifications. Write to support and we will look into it.
A lesson that goes beyond Zabbix
What happened to our Zabbix catalogue will sooner or later happen to any image that depends on a specific release. That is why our AMIs install each component from its project’s official repository and follow supported lines, and why we review each product’s calendar before AWS does: when the system or the software approaches end of life, the migration has to be done before the scan says so.
