Guidance Required for Wazuh Architecture, Hardware & Storage Sizing

365 views
Skip to first unread message

Eswar Prasath

unread,
Jul 2, 2025, 5:26:47 AM7/2/25
to Wazuh | Mailing List

Dear Wazuh Community,

We are in the process of planning a centralized Wazuh deployment and would appreciate your guidance in defining the architecture, hardware, and storage requirements based on our environment and log retention needs.

Environment Overview:

  • Office Locations: 5 different sites

  • Assets:

    • 100 servers

    • 500 endpoints (Windows/macOS/Linux)

    • 10 firewalls

    • 5–10 other network devices (e.g., switches, routers)

Retention Requirements:

  • We need to retain both archive logs and alert data for a minimum of 90 days.

We would like your recommendations or sizing guidelines for the following:

  1. Appropriate deployment architecture (single node vs multi-node vs distributed with worker nodes)

  2. Recommended hardware specs (CPU, RAM, storage) for the Wazuh Manager, Indexer, and Dashboard components

  3. Storage estimates for 90 days of alert and archive logs

  4. Any best practices or reference architectures for multi-site environments

Thank you in advance for your support and advice.

Best regards,
Eswar

Cedrick Foko

unread,
Jul 2, 2025, 7:31:15 AM7/2/25
to Wazuh | Mailing List
Hello,

Based on your environment and requirements, here are the recommendations for your Wazuh deployment:

For your environment (5 sites, 100 servers, 500 workstations, 15-20 network devices), it is recommended to deploy a multi-node cluster with:

1. 3-node Wazuh Manager cluster (1 master node + 2 worker nodes
2. 3-node Wazuh indexer cluster (with dashboard running on one of the indexers)

This provides:
- High availability
- Load distribution
- Scalability for future growth
- Better performance than single-node

Regarding the minimum hardware, having 8vCPUs and 16GB of RAM for each node would be enough.

Regarding storage estimation
For 100 servers+500 workstations with 90-day retention:

1. Alert data (Wazuh Indexer) estimations:
   - 3.7GB/server/90 days
   - 1.5GB/workstation/90 days
   - 7.4GB/network devide/90days
   - 100 servers x 3.7GB + 500 workstations x 1.5GB + 20 network devices x 7.4GB = ~1268GB
   - Add 20% overhead = 1521.6GB (shared across the 3 nodes)

2. Archive logs (Wazuh Manager) estimations:
   - 0.1GB/server/90 days
   - 0.04GB/workstation/90 days
   - 0.2GB/network devide/90days
   - 100 servers x 0.1GB + 500 workstations x 0.04GB + 20 network devices x 0.2GB = ~34GB
   - Add 20% overhead = 40.8GB (shared across the 3 nodes)

Please keep in mind that the amount of data depends on the generated alerts per second (APS) in your environments.
These values are only estimations, and you may not apply exactly depending on the load.

You can find more information in the following references:

Eswar Prasath

unread,
Jul 7, 2025, 3:01:15 AM7/7/25
to Wazuh | Mailing List

Hello Cedrick and Wazuh Team,

Thank you for your detailed recommendations.

We would like to explore the possibility of using 2 servers each for the Wazuh Manager and Indexer clusters (a total of 4 servers) instead of 3 nodes per cluster, but with increased CPU and RAM specifications on those servers.

Could you please advise if this configuration would still provide adequate performance, scalability, and high availability for our environment (5 sites, 100 servers, 500 endpoints, and 15–20 network devices) with 90-day retention?

Also, if you could recommend the adjusted hardware specs (CPU, RAM, storage) per node for this 2-node cluster setup, that would be very helpful.

Looking forward to your guidance.

Best regards,
Eswar

Cedrick Foko

unread,
Jul 9, 2025, 4:49:53 AM7/9/25
to Wazuh | Mailing List
Hello,
The architecture I provided earlier outlines the minimum requirements for sizing your environment. 
Reducing the number of nodes will affect performance.

However, if you want to use exactly two managers and two indexers, you can increase the number of virtual CPUs to 12 and the amount of RAM to 32 GB per node.
Reply all
Reply to author
Forward
0 new messages