Zabbix 7.0 is the first LTS line since 6.0, and it brings the most visible change in years: a rebuilt frontend, a more efficient collection engine and a native SLA system. At imaxe we've repackaged all of that into a production-ready AMI on Ubuntu 24.04, with our SQS reader rewritten to take advantage of the new APIs.
If you already run one of our Zabbix 6.0 AMIs, this guide tells you what your team gains by updating and how to do it without losing a single point of history.
The AMI Zabbix 7.0 LTS is now available on AWS Marketplace in the 7 usual commercial regions. 6.0 LTS is still maintained until 2027-02, so there's no rush to migrate.
A frontend that finally feels modern #
The change you notice most as soon as you log in. Dashboards now support multi-page widgets with automatic rotation, ideal for NOC screens, and navigation has been flattened: fewer clicks to reach a specific problem.
- Redesigned top hosts, gauge and pie widgets, with configurable color thresholds.
- Improved kiosk mode for wall panels, with independent refresh per widget.
- Per-user saved filters that persist between sessions.
Native SLA, no juggling #
Until now, calculating a decent SLA in Zabbix meant triggers helper items and manual calculations. 7.0 introduces a first-class SLA service: you define the target, the service windows and the planned downtime periods, and Zabbix does the rest.
We went from maintaining a parallel spreadsheet to having SLA compliance on the same dashboard as the rest of the metrics. That alone justifies the update.
Excluding maintenance windows
The calculation respects maintenance periods, so a planned restart doesn't penalize your availability. You configure it once and it applies to all associated services.
The triggers helper items you used for SLA in 6.0 don't convert on their own. Note down your current targets to rebuild them with the new service.
Rewritten SQS reader #
Our auto-scaling integration reads Auto Scaling events from an SQS queue to deregister instances that disappear. In 7.0 we've rewritten it to use the async client and process batches, cutting deregistration latency from minutes to seconds.
The configuration doesn't change: it still lives in /etc/zabbix/zabbix_ami.yml. If you're coming from 6.0, your file is compatible as is.
$ imaxe status zabbix-sqs-reader
→ version 3.0.1 (async) · queue connected
→ last batch: 4 messages in 0.8s
$ journalctl -u zabbix-sqs-reader -n 20 --no-pagerHow to migrate from 6.0 #
We recommend migrating by launching a new instance with the 7.0 AMI and moving the data, rather than updating in place. It's safer and leaves you a way back.
- Launch the Zabbix 7.0 LTS AMI in the same region and an equivalent instance type.
- Export the database from the 6.0 instance and restore it on the new one — the schema updates on first boot.
- Copy
/etc/zabbix/zabbix_ami.ymland your custom templates. - Verify agents and alerts in parallel for 24-48 h before moving the EIP.
The included imaxe-zabbix-migrate tool automates the dump, the load and the schema verification. We document it step by step on the AMI page.
Is it worth it? #
If you live in the dashboards or need to report on SLA, 7.0 is a clear leap. If your 6.0 works and you don't use SLA, there's no urgency: we'll keep it patched and audited until 2027. Either way, the new AMI is ready whenever you are.