Wazuh Environment

11 views
Skip to first unread message

Brenno Garcia

unread,
May 19, 2026, 12:28:44 PM (4 days ago) May 19
to Wazuh | Mailing List
Hello,

How many OCI resources are needed for a Wazuh with 600 agents?
My initial idea was to run a all-in-one stack deployment.

Olamilekan Abdullateef Ajani

unread,
May 19, 2026, 1:05:05 PM (4 days ago) May 19
to Wazuh | Mailing List
Hello Brenno,

First, you can find the architecture and deployment recommendations in the documentation below:
https://documentation.wazuh.com/current/quickstart.html

Generally, sizing Wazuh instance is less about the number of agents alone and more about how much data those agents are actually generating. The main things to consider are:

- EPS (events per second) - affects CPU and RAM usage
- Log volume/noise level - affects processing and indexing performance
- Retention period (30/60/90 days, etc.) - affects disk usage

For example, 600 quiet endpoints sending minimal logs will behave very differently from 600 servers generating high event volumes.

For your environment size, starting with an all-in-one deployment on OCI would be my advice. You can begin with something around

- 16 vCPU
- 16 GB RAM
- 1–2 TB storage (depending on retention and log volume)

Then monitor how the environment behaves and scale from there if needed.

You should especially keep an eye on the statistics files below:

/var/ossec/var/run/wazuh-analysisd.state:
The events_dropped variable indicates if events are being dropped due to insufficient processing resources.

/var/ossec/var/run/wazuh-remoted.state:
The discarded_count variable indicates whether messages from agents are being discarded.

Reference:
https://documentation.wazuh.com/current/user-manual/reference/statistics-files/index.html

Wazuh does not really have a strict "max EPS per node." In most cases, the limit depends on the available hardware and how much workload the node is handling.

In summary, my recommended approach is
- Start with an all-in-one deployment
- Monitor EPS, storage growth, and dropped/discarded events
- Then scale horizontally (by adding nodes and creating clusters) only if the workload requires it.

This will give better visibility into the actual resource requirements of your environment instead of over-sizing from the beginning.
Reply all
Reply to author
Forward
0 new messages