Zabbix Monitoring Tool: Complete Guide, AWS Setup and Best Practices (2026)

Zabbix is an open-source monitoring tool that collects metrics from servers, network devices, cloud services and applications, evaluates them against triggers, and alerts people when something is wrong. It has been in production use since 2001, is released under the AGPL, and is one of the few enterprise-grade monitoring platforms you can run without a per-host licence.

This guide is in two halves. The first explains what Zabbix is, how it is built, and when it is the right choice compared with CloudWatch, Nagios, Prometheus or Datadog. The second is the deployment we run for clients on AWS: EC2, RDS, load balancers and auto-scaling groups, with the compliance and cost decisions written down.

What the Zabbix monitoring tool actually does

Zabbix does four things, in order:

1. Collects data. Agents on hosts, SNMP and IPMI for hardware and network gear, HTTP and API checks for cloud services, JMX for Java, ODBC for databases, and scripts for anything else.
2. Stores it. Time-series values go into MySQL, PostgreSQL or TimescaleDB. Retention is per item, so a CPU value can be kept for a week at full resolution and a year as hourly trends.
3. Evaluates triggers. A trigger is an expression over collected values: "average CPU over 5 minutes above 90%", "no data from this host for 3 minutes", "disk will be full within 24 hours based on current growth". Triggers have severities and can depend on each other, so a dead switch does not fire alerts for every host behind it.
4. Acts. Actions send email, Slack, Teams, PagerDuty, Opsgenie or SMS, run remote commands, open tickets, and escalate if nobody acknowledges within a set time.

On top of that it provides dashboards, maps, SLA reporting, an audit log, an API for automation, and role-based access so a client can see their own hosts and nothing else.

Zabbix architecture

A production Zabbix installation has five components:

• Zabbix server — the core process. Receives data, evaluates triggers, runs actions. Since Zabbix 6.0 it supports native high availability: two or more servers share the database, one is active, failover is automatic.
• Database — MySQL, MariaDB, PostgreSQL or PostgreSQL with TimescaleDB. TimescaleDB is the right choice above a few thousand hosts; it compresses history and makes housekeeping cheap.
• Web frontend — PHP application (NGINX or Apache) for dashboards, configuration and the API.
• Zabbix proxy — an optional collector that sits close to the monitored hosts, buffers data locally and forwards it to the server. Proxies are how you monitor a remote site, a second AWS region, or a customer VPC without opening every host to the central server.
• Zabbix agent 2 — the on-host collector. Written in Go, plugin-based, with built-in support for Docker, PostgreSQL, MySQL, Redis, MongoDB, systemd and more. Agents work in passive mode (server polls the agent on port 10050) or active mode (agent pushes to server or proxy on port 10051). Active mode is what you want behind NAT and in auto-scaling groups.

Ports to remember: 10050 (agent, inbound), 10051 (server/proxy trapper, inbound to server), 80/443 (frontend).

Key concepts: hosts, templates, items, triggers, discovery

• A host is anything you monitor. A host group is how you scope permissions and actions.
• A template is a reusable bundle of items, triggers, graphs and discovery rules. Zabbix ships with several hundred official templates: Linux, Windows, NGINX, Apache, PostgreSQL, MySQL, Redis, Docker, Kubernetes, VMware, Cisco, Juniper, AWS, Azure, GCP. Link a template to a host and the monitoring is done.
• An item is one metric: system.cpu.util, vfs.fs.size[/,pused], net.if.in[eth0].
• A trigger is a condition on items. Good triggers use functions like avg(), min(), nodata(), forecast() and timeleft() rather than a single sample.
• Low-level discovery (LLD) finds things automatically: filesystems, network interfaces, Docker containers, RDS instances, EC2 instances via the AWS API. Discovered entities get prototype items and triggers, so a new disk or a new EC2 instance is monitored without anyone editing configuration.
• Macros parameterise everything. {$CPU.UTIL.CRIT} on a template can be overridden per host group or per host, so one template serves both a batch server that runs hot and a web tier that should not.

When to choose Zabbix (and when not to)

Zabbix is the right tool when you need:

• No per-host or per-metric licence. Cost is your infrastructure and your engineers. For 200 hosts that is one or two EC2 instances and an RDS database, not a five-figure annual bill.
• Infrastructure-first monitoring. Servers, VMs, network devices, hypervisors, databases, storage. It is unusually good at SNMP and hardware.
• Data sovereignty. All metrics stay in your VPC or data centre. Relevant for PCI DSS, HIPAA, GDPR, RBI and government workloads.
• Hybrid and multi-site estates. Proxies make on-premises plus AWS plus a colocation rack one console.
• Predictive alerting. forecast() and timeleft() are built in; you do not need a separate anomaly product to know a disk fills in 20 hours.

Zabbix is the wrong tool, or only part of the answer, when you need:

• Application performance monitoring (APM). Distributed tracing, code-level profiling and request waterfalls are not what Zabbix does. Pair it with OpenTelemetry plus Jaeger or Tempo, or with a commercial APM.
• Log analytics at scale. Zabbix can tail a log file and alert on a pattern. It is not Elasticsearch or Loki.
• Kubernetes-native metrics with PromQL. Zabbix has a Kubernetes template and Prometheus scraping, but if your team lives in PromQL and Grafana, Prometheus is the more natural fit for the cluster itself. Many estates run both: Prometheus inside Kubernetes, Zabbix for everything around it.
• Zero operational overhead. Someone has to patch the server, size the database and tune housekeeping. A managed NOC service covers this if you do not want to.

Zabbix vs CloudWatch vs Nagios vs Prometheus vs Datadog

	Zabbix	AWS CloudWatch	Nagios Core	Prometheus + Grafana	Datadog
Licence	Open source (AGPL)	Pay per metric, alarm, log GB	Open source (GPL)	Open source (Apache 2)	Commercial, per host + per feature
Best at	Infrastructure, hybrid, SNMP, hardware	AWS-native services	Simple up/down checks	Kubernetes, cloud-native, PromQL	All-in-one SaaS with APM and logs
Data location	Your infrastructure	AWS	Your infrastructure	Your infrastructure	Datadog SaaS
Auto-discovery	Yes (LLD, cloud APIs)	AWS only	Plugins	Service discovery	Yes
Predictive triggers	Built in	Anomaly detection (paid)	No	Via recording rules	Yes
Typical cost at 200 hosts	Infra only, roughly $150 to $300/month on AWS	Varies; custom metrics and alarms add up fast	Infra only	Infra only	Thousands per month
Operational effort	Medium	Low	Medium to high	Medium	Low

The honest summary: CloudWatch for what only AWS can see (service quotas, billing, Lambda internals), Zabbix for the estate as a whole, Prometheus if Kubernetes is the centre of your world, Datadog if budget is not the constraint and you want APM in the same pane. A full comparison of Zabbix, Nagios and Datadog is on our blog.

Deploying Zabbix on AWS: step by step

This is the reference deployment we use for clients with 50 to 2,000 hosts. Adjust sizes, not structure.

Phase 1: Infrastructure (roughly $150 to $300 per month)

Zabbix server. One EC2 instance in a private subnet. A t3.large or t4g.large (Graviton is cheaper and Zabbix packages for arm64 exist) handles a few hundred hosts comfortably. For HA, two instances in different Availability Zones with the HA cluster feature enabled in zabbix_server.conf (HANodeName, NodeAddress).

Database. Amazon RDS for PostgreSQL, db.t4g.medium to start, Multi-AZ for production, storage autoscaling on. Install the TimescaleDB extension if your RDS engine version supports it; otherwise plan for aggressive housekeeping or a self-managed PostgreSQL on EC2 with TimescaleDB.

Frontend. Either on the server instance behind an Application Load Balancer with an ACM certificate, or on its own small instance. Restrict the ALB to your office and VPN CIDRs, or put it behind AWS SSO / an identity-aware proxy.

Proxies. One Zabbix proxy per additional VPC, region or on-premises site. Proxies talk to the server on 10051 only, so peering or Transit Gateway rules stay minimal.

Network. Security groups: agents accept 10050 from the server and proxy only; server accepts 10051 from proxies and active agents; frontend accepts 443 from the ALB. No public IPs on the server or database.

Backups. RDS automated backups with 7 to 35 days retention plus a weekly pg_dump of the configuration tables to S3. Export templates and host groups via the API on a schedule so you can rebuild from code.

Phase 2: EC2 monitoring

1. Install Zabbix agent 2 via the official repository in your AMI or user-data, configured in active mode with ServerActive pointing at the proxy or server and HostMetadata set to something like linux aws prod web.
2. Create an auto-registration action: when a new agent registers with metadata matching aws prod web, add it to the right host group and link the Linux by Zabbix agent template plus your web-tier template. Instances that auto-scale in are monitored within a minute; instances that terminate are removed by a scheduled API job or by a nodata() trigger that disables the host.
3. Link the AWS EC2 by HTTP template on a discovery host with an IAM role that allows ec2:Describe* and cloudwatch:GetMetricData. This pulls instance status checks, CPU credit balance and EBS metrics that the agent cannot see.
4. Set thresholds with macros, not by editing triggers: {$CPU.UTIL.CRIT}=90, {$VFS.FS.PUSED.MAX.CRIT}=85, {$MEMORY.UTIL.MAX}=90, tuned per host group.

Phase 3: RDS and database monitoring

• Link AWS RDS by HTTP for CloudWatch-side metrics: CPU, freeable memory, free storage, read/write IOPS, replica lag, connection count.
• Add PostgreSQL by Zabbix agent 2 or MySQL by Zabbix agent 2 on a bastion or proxy host that can reach the database, using a read-only monitoring user. This gives you what CloudWatch does not: long-running queries, lock waits, cache hit ratio, replication slots, table bloat.
• Triggers that matter: free storage below 15% with timeleft() under 48 hours, replica lag above 30 seconds, connections above 80% of max_connections, deadlocks per minute rising.

Phase 4: Load balancers and auto-scaling

• AWS ELB Application Load Balancer by HTTP template: request count, target 5xx rate, ELB 5xx rate, unhealthy host count, target response time p95. Alert on unhealthy hosts greater than zero for five minutes and on 5xx rate above 1% of requests.
• Auto Scaling Group items via CloudWatch: desired versus in-service capacity. A trigger on desired > in-service for more than ten minutes catches launch failures before customers do.
• Synthetic checks from the proxy: an HTTP agent item hitting your health endpoint every 30 seconds with a trigger on response code or latency. This is the "is the site actually up" check that internal metrics cannot replace.

Phase 5: Alerting, escalation and on-call

• Route by severity. Warning goes to Slack or Teams. High and Disaster go to PagerDuty or Opsgenie with escalation after 15 minutes unacknowledged.
• Use trigger dependencies so a proxy outage produces one alert, not two hundred.
• Set maintenance windows for patch nights. Alerts suppressed during maintenance are still recorded.
• Put runbook links in trigger URLs. The person woken at 3am should have the fix one click away.

Zabbix best practices for production

• Templates in git. Export templates as YAML through the API and version them. Changes go through review like any other code.
• Housekeeping tuned from day one. Default history of 90 days at full resolution for every item will sink the database. Set 7 to 14 days history and 365 days trends for most items; keep longer only where you need it.
• Active agents by default. Passive polling of thousands of hosts is what makes Zabbix servers slow.
• Proxies for scale and isolation. One proxy per 500 to 1,000 hosts, and never let a proxy outage hide an entire site: monitor proxies from the server with zabbix[proxy,<name>,lastaccess].
• Monitor Zabbix itself. Queue length, poller busy percentage, cache usage and database size are all exposed as internal items. A busy-poller alert is the early warning that you need another proxy or bigger instance.
• Least-privilege access. User groups per client or team, read-only by default, API tokens with expiry for automation.
• Test the alert path monthly. Fire a test trigger and confirm it reaches the on-call phone. Silent monitoring is worse than none.

Compliance and enterprise requirements

For regulated estates Zabbix covers the monitoring controls that auditors look for:

• PCI DSS requirement 10 and 11: audit logging of who changed what in Zabbix, alerting on failed logins and configuration changes on in-scope hosts, file integrity checks via vfs.file.cksum.
• SOC 2 availability criteria: documented alerting thresholds, escalation with timestamps, and SLA reports from the Services feature to show uptime against commitments.
• ISO 27001 A.12 operations security: capacity monitoring, event logging, and evidence that alerts were acknowledged and resolved.
• Data residency: metrics never leave your AWS account or region.

Certification and audit work itself sits with our sister firm PraxisQ Consulting; the monitoring controls and their evidence are delivered by the NOC.

Common Zabbix problems and fixes

Database grows without limit. Housekeeping is disabled or the history period is too long. Enable housekeeping, reduce history retention, move to TimescaleDB with compression.

"Zabbix poller processes more than 75% busy." Too many passive checks or slow SNMP targets. Switch agents to active, add pollers in zabbix_server.conf, or introduce a proxy.

Auto-scaled instances show as unavailable after termination. Add a scheduled job that calls the API to delete hosts whose EC2 instance no longer exists, or use the AWS EC2 discovery template so lifecycle is handled by LLD.

Alert storms during a network event. Missing trigger dependencies. Make host-level triggers depend on the upstream switch, router or proxy trigger.

Frontend slow with many users. Put the frontend on its own instance, enable PHP opcache, and give the database more memory for the configuration cache.

Zabbix on AWS: frequently asked questions

How do I monitor AWS Lambda with Zabbix?

Lambda has no host to install an agent on. Use the AWS Lambda by HTTP template, which pulls invocations, errors, duration and throttles from CloudWatch through the API, and add HTTP agent checks against the function's API Gateway endpoint for end-to-end latency.

What does Zabbix cost compared with CloudWatch?

Zabbix costs whatever its infrastructure costs: for a typical 200-host estate, roughly $150 to $300 per month on AWS for the server, proxy and RDS. CloudWatch is priced per custom metric, alarm, dashboard and log gigabyte, so cost scales with how much you monitor rather than how many hosts you have. Many teams run both and keep CloudWatch to the AWS-only metrics.

Can Zabbix meet a SOC 2 on-call SLA?

Yes. Escalation steps with acknowledgement tracking, an immutable audit log, and SLA reporting give auditors the evidence. The SLA itself is a people-and-process commitment; Zabbix records whether it was met.

Can Zabbix replace Datadog for AWS APM?

For infrastructure monitoring, yes. For APM (traces, profiling, RUM), no. Pair Zabbix with OpenTelemetry and an open-source tracing backend, or keep Datadog APM and let Zabbix handle the estate.

What happens if the Zabbix server fails in one Availability Zone?

With the HA cluster enabled and a Multi-AZ RDS, the standby node in the other AZ takes over within the failover delay (default one minute). Proxies buffer data locally in the meantime, so nothing is lost.

Is Zabbix agent 2 required, or will the classic agent do?

Both work. Agent 2 is the current default: it is plugin-based, supports more targets natively, and is where new features land. Use it for new deployments.

Managed Zabbix monitoring from Techtweek Infotech

We design, deploy and run Zabbix for clients in the UK, US, Australia, UAE, Singapore and India as part of our NOC monitoring services: 24/7 alert handling, monthly tuning, template management in git, and integration with your on-call tooling. If you would rather own the platform and have us build it, we do that too as a fixed-scope project.

Related reading: server maintenance and management services, AWS global infrastructure guide, and our Kubernetes consulting for AWS guide for cluster-side monitoring.