# Signal Sentry vs Wazuh in Production: What One AWS Team Learned the Hard Way

*By Shivam Sharma, DevOps Engineer at Dedups · 13 October 2026*

Wazuh is a good open-source SIEM. It is free, it has a large community, and for host-based monitoring it does a lot. But "runs in a lab" and "runs in production on AWS" are two different tests, and many teams only find that out after six months of operating it.

This article walks through the real feedback from one such team, explains how we checked it, and shows how Signal Sentry - the enterprise SIEM from Dedups - is built to avoid each of those problems. Where Wazuh still fits, we say so. Where we don't have a number, we say that too.

## Who the customer is

The feedback below comes from an **automotive company headquartered in India**. They run **51 AWS accounts** and send roughly **5 GB of logs a day** - AWS WAF, VPC Flow Logs and CloudTrail - into their SIEM. They asked not to be named, and we have respected that. Everything else is as they wrote it.

This is not a huge estate. That is the point: these problems showed up at 51 accounts and 5 GB/day, not at 1,000 accounts and terabytes.

## The customer's experience with Wazuh

Quoted as they sent it to us:

> **Delayed log ingestion.** Logs were retrieved from AWS at scheduled intervals rather than in real time. Given the size of our infrastructure, this caused delays ranging from several minutes to hours.
>
> **Incomplete or duplicate data.** Some log files were skipped or processed more than once.
>
> **Poor search performance.** Queries over longer time periods or large data volumes were slow and frequently timed out on the dashboard.
>
> **Limited log visibility.** By default, Wazuh stores only events that trigger alerts. Retaining complete WAF and VPC logs required additional configuration and roughly doubled storage requirements.
>
> **Inability to handle high log volumes.** The volume and size of VPC Flow Logs and WAF logs exceeded the system's processing capacity, resulting in dropped events.
>
> **Excessive alert noise.** A large number of low-priority alerts made it difficult to identify genuine security incidents.
>
> **High operational cost and maintenance effort.** The platform required large servers and storage, stopped ingesting data when disks reached capacity, and was prone to issues during upgrades, demanding significant ongoing effort from the team.

None of these are unusual. Search the Wazuh forums for "VPC flow logs", "S3 bucket delay" or "indexer disk full" and you will find the same seven complaints in different words. They are not bugs so much as consequences of how Wazuh is designed: an endpoint-first agent platform that later grew cloud log collection on the side.

## How we compared the two

We did not want to compare their Wazuh on their hardware against our product on ours. So we matched the setup:

- **Wazuh Community edition**, self-hosted, as the customer ran it in the POC. No paid Wazuh Cloud tier was involved.
- **Same logs.** The customer's own WAF, VPC Flow and CloudTrail feed, about 5 GB/day across 51 accounts.
- **Same machine.** One r5.xlarge with 250 GB of storage for Wazuh, and the same r5.xlarge with 250 GB for Signal Sentry.
- **Same region.** Both ran in the customer's AWS region, so data-transfer cost was negligible on both sides and is not part of the comparison.
- **Same questions.** The long-time-range searches that were timing out on the Wazuh dashboard.

On that setup, the searches that timed out in Wazuh completed in Signal Sentry. We are preparing a follow-up with the exact query list and timings, and we will link it here when it is published. Until then, treat "completed vs timed out" as the claim, not a specific millisecond figure.

The 141 ms / 2.88 million findings number you will see on our product page is from a different, much larger reference deployment. It is a real figure, but it is not from this test, so we have not used it in the comparison below.

## The seven problems, one at a time

### 1. Delayed ingestion

Wazuh pulls AWS logs from S3 on a schedule through its `aws-s3` wodle. Each run has to list the bucket, work out what is new, download it and parse it. When CloudTrail and WAF are writing thousands of objects an hour, that loop takes longer than the interval, and the backlog grows - for this customer, to hours.

Signal Sentry also reads in batches. We want to be straight about that: it syncs every **15 minutes**, and the typical lag from an event landing in AWS to it appearing in a finding is **about 25 minutes**. It is not real time, and we do not call it that.

The difference is that you can see the lag. The freshness screen reads the newest event in the findings index itself and reports, per source, "last sync: 25m ago, batch: 1,532 docs, window ending 15:44:27". A stalled feed is visible the moment it stalls, not a week later when someone asks why an incident has no logs. The customer's Wazuh lag was invisible until it was hours.

![Signal Sentry's findings-over-time chart: one bar per day, so a volume spike or a gap in the feed is visible the same day it happens.](/assets/blog-images/signal-sentry-vs-wazuh-production/findings-over-time.webp)

### 2. Skipped and duplicated log files

When a scheduled puller falls behind, it has to track which objects it has already seen. Get that wrong one way and files are skipped; get it wrong the other way and they are processed twice. Both happened to this team.

Signal Sentry's pipeline is built around joining events, not just storing them. Events about the same thing - the same source IP, the same IAM principal, the same request path - are put together into one finding. A log line that arrives twice lands on the same finding rather than becoming a second alert, and the per-source document counts on the freshness screen let you reconcile what was read against what AWS delivered.

### 3. Slow searches that time out

Wazuh stores data in its own indexer (an OpenSearch fork). It works, but long time-range queries over WAF and VPC data are heavy, and the dashboard times out well before the indexer does. On an r5.xlarge with 5 GB/day, this customer hit that wall regularly.

On the same r5.xlarge, the same searches completed in Signal Sentry. You can type a query (`severity:critical AND dst_port:[5000 TO 6000]`) with autocomplete, or click filters for source, severity, threat, port and WAF outcome - same result either way. Drag across the chart to narrow the time window without rewriting the query, and save the searches you run every morning.

### 4. Only alerting events are kept by default

This is the one that surprises most teams. Out of the box, Wazuh keeps the events that matched a rule. The rest - the vast majority of WAF and VPC traffic - is discarded unless you turn on full archive logging, which roughly doubles storage. This team found the "retain everything" setting cost them twice the disk.

Signal Sentry starts from the opposite assumption: you already pay AWS to store every log line, so the SIEM should read all of them. It works from the logs you already keep, read-only, with nothing installed on your servers. There is no "alerts only" mode to grow out of.

### 5. Dropped events under load

VPC Flow Logs and WAF logs are high-volume by nature. When Wazuh's manager or indexer cannot keep up, events are dropped silently - the hardest kind of gap to notice in an investigation.

In Signal Sentry, cluster health - CPU, memory, disk, indexer status, log errors - sits on the same screen as the data, so capacity pressure is visible before it turns into dropped events. The per-source document counts give you a number to check against what AWS says it delivered. We have not yet published a dropped-event count from the matched test; when we do, it will be in the follow-up linked above.

### 6. Too many low-priority alerts

Wazuh ships thousands of rules. Most fire at level 3 to 5 and most are noise in a cloud context. Tuning them is a project in itself, and this team never got to the point where a critical alert stood out.

Signal Sentry does not hand you raw rule matches. Every finding arrives with the attack already named - broken auth / JWT probing, SSRF, IAM privilege escalation, Layer-7 DoS - mapped to its MITRE ATT&CK ID and scored. Critical, High and Medium are counted apart so Medium findings cannot bury the Critical ones. Traffic your WAF blocked is counted separately from traffic that reached origin, because only one of those is tonight's problem. The result is 25 named use cases instead of a few thousand rules.

![Signal Sentry's use-case coverage table: each attack named, given a severity and a MITRE ATT&CK technique ID, sorted by finding count. Click a row to see the events behind it.](/assets/blog-images/signal-sentry-vs-wazuh-production/use-case-coverage-mitre.webp)

### 7. Large servers, full disks, painful upgrades

Self-hosting Wazuh means a manager, an indexer and a dashboard, each with its own storage, each needing upgrades that occasionally break. When the indexer disk fills, ingestion stops and nobody is told. For this team, that meant a DevOps engineer's time every week on a tool that was supposed to save it.

Signal Sentry is run by Dedups. You give read-only access to the log sources you already have; we run the platform, the storage and the upgrades. The operational effort on your side is the walkthrough call and reading the findings.

## What it costs

Wazuh is free to download. Running it is not. For this customer the bill was an r5.xlarge instance with 250 GB of storage (which filled once full WAF and VPC retention was turned on), and the engineer hours spent on backlogs, duplicates, full disks and upgrades. Data transfer was not a factor - everything stayed in one AWS region.

Here is what that single-node, non-HA Wazuh box costs on AWS in Mumbai (ap-south-1), on-demand Linux pricing, before any reserved-instance discount:

| Item | Rate | Monthly | Yearly |
|---|---|---|---|
| r5.xlarge (4 vCPU, 32 GiB), on-demand | $0.260/hr x 730 hr | $190 | $2,278 |
| 250 GB gp3 EBS | $0.0912/GB-month | $23 | $274 |
| **Infrastructure total** | | **$213** | **$2,552** |
| Same box with full retention (500 GB) | | $235 | $2,826 |
| Engineer time on backlogs, duplicates, disk, upgrades | hours/month x your rate | ? | ? |

A 1-year reserved instance takes roughly a third off the compute line. The engineer line is the one that matters and the one nobody budgets: for this team it was a DevOps engineer's attention every week. And this is a single node - if you want Wazuh to survive the loss of that one machine, you are running at least two of everything.

Prices are from public AWS pricing for ap-south-1 as of October 2026; check the AWS calculator for your region.

Signal Sentry is sold as an **annual enterprise plan**. It is not priced per GB ingested - log volume within a region costs us little to move, so we do not charge you for it. We do not publish a price list because the figure depends on your accounts, sources and retention; tell us your setup and we will give you a number on the first call, before any demo.

## Side by side

| | Wazuh (self-hosted) | Signal Sentry |
|---|---|---|
| **AWS log collection** | Scheduled S3 pull; lag grew to hours for this customer | 15-min sync batches; ~25 min typical lag |
| **Can you see the lag?** | No | Yes - measured from the index, per source |
| **Duplicate handling** | Depends on puller state tracking | Related events joined into one finding |
| **Long-range search (r5.xlarge, 250 GB, 5 GB/day)** | Dashboard timed out | Completed |
| **Full log retention** | Off by default; roughly 2x storage when on | Reads every log line you already keep |
| **Alert model** | Thousands of rules, mostly low level | 25 named attacks, MITRE-mapped, scored |
| **Blocked vs reached** | Not separated | WAF defended vs reached origin, counted apart |
| **Who runs the servers** | Your team | Dedups |
| **What to install** | Agents + manager + indexer + dashboard | Nothing; read-only log access |
| **Cost model** | Free software; your infra and people | Annual plan; not metered per GB |
| **Best for** | Host/endpoint monitoring, FIM, compliance checks on servers | AWS estates with heavy WAF/VPC/CloudTrail volume |

## Where Wazuh is still the right call

We would be doing you a disservice if we pretended otherwise.

- **Endpoint and host monitoring.** Wazuh's agent does file integrity monitoring, rootkit detection, vulnerability detection and log collection on the host. Signal Sentry does not run an agent; it reads cloud logs.
- **Budget is zero.** Wazuh is genuinely free. If your log volume is small and someone on the team enjoys running it, the problems above may never bite.
- **Compliance checkboxes on servers.** PCI DSS and CIS benchmark checks at the OS level are a Wazuh strength.

## Running both

You do not have to rip Wazuh out. The setup we see most often: keep Wazuh agents on hosts for FIM and OS-level compliance, and point the AWS log sources - WAF, VPC Flow, CloudTrail - at Signal Sentry. Wazuh stops carrying the volume that was breaking it, and the cloud attack surface gets a tool built for it.

## What switching looks like

- **Day 0:** you create a read-only IAM role for the log buckets. Nothing is installed on your servers.
- **First sync:** within the hour. First findings on the same day.
- **First week:** we walk through what it found on a call, with engineers, no slides.
- **Wazuh:** untouched. Turn its AWS wodle off when you are ready, or leave it running in parallel.

## Corrections

I run the DevOps side of Signal Sentry deployments, so this is written from inside the company. If you run Wazuh and think a claim above is wrong or unfair, email us through the [contact page](/contact-sales) and we will correct it here with a note.

[See the Signal Sentry product page](/signal-engine-siem) · [Book a walkthrough](/book-demo) · [Talk to our team](/contact-sales)