Sizing Wazuh and OpenSearch: Retention and Storage Maths

As of 11 October 2026. Workload figures in the examples are assumptions. Measure your own event rates and index sizes during a pilot before buying hardware.

Size from data, not from agent count

Wazuh publishes a starting point for an all-in-one deployment, with the server, indexer and dashboard on one host. For version 4.14 its quickstart lists, for 90 days of indexed alerts:

That table is a reasonable floor for a small pilot. Beyond it, agent count is a poor predictor: a domain controller or firewall can generate many times the events of a quiet workstation, and enabling archives (all events, not just alerts) multiplies storage. Size the indexer from measured volume.

Step 1: estimate daily volume

daily volume (GB) = events per second × average document size (KB) × 86,400 / 1,000,000

Illustrative example: 200 indexed alerts per second at an average of 1.5 KB each gives 200 × 1.5 × 86,400 / 1,000,000 ≈ 25.9 GB a day. Get real numbers by running a pilot for a week and reading the daily index sizes with the _cat/indices API.

Step 2: add replicas, overhead and headroom

AWS’s guidance for OpenSearch Service gives a storage formula that also works as a checklist for self-managed clusters:

minimum storage = source data × (1 + replicas) × (1 + indexing overhead)
                  / (1 − Linux reserved space) / (1 − service overhead)

AWS uses about 10% indexing overhead, 5% Linux reserved space and 20% service overhead (the last is specific to its managed service), simplifying to source × (1 + replicas) × 1.45. For a self-managed Wazuh indexer, drop the managed-service term but keep comparable headroom for segment merges and disk watermarks; we plan at least 20–25% free space.

Continuing the example with 90 days of retention and one replica:

source data     = 25.9 GB/day × 90 days            ≈ 2,333 GB
with replica    = 2,333 × 2                         ≈ 4,666 GB
with overhead   = 4,666 × 1.10 / 0.95               ≈ 5,402 GB
with 25% free   = 5,402 / 0.75                      ≈ 7,203 GB  → plan ~7.2 TB across indexer nodes

Step 3: check shard counts and heap

AWS recommends shards of 30–50 GiB for write-heavy workloads such as log analytics, and no more than 25 shards per GiB of Java heap on a node. Daily indices make shard counts grow with retention:

daily index ≈ 25.9 GB × 1.1 ≈ 28.5 GB  → 1 primary shard per day, just under the 30–50 GiB range
90 days     → 90 primaries + 90 replicas = 180 shards
heap needed → at least 180 / 25 ≈ 7.2 GiB of heap across the indexer nodes

Small daily indices with several primary shards each are a common cause of oversharding. If daily volume is small, fewer primary shards per index (or longer index periods) keep the shard count down.

Step 4: decide the cluster shape

Three indexer nodes is a common minimum for a resilient cluster because it allows a cluster manager quorum and a replica on a different node from its primary. Retention beyond what you search day to day is cheaper as snapshots to object storage, restored when an investigation needs them.

Retention: decide it, do not inherit it

Retention is often set by regulation or contract rather than by disk size. In India, CERT-In’s directions require ICT system logs to be kept for a rolling 180 days within Indian jurisdiction, which may be longer than a default 90-day index policy. Check every requirement that applies to you, then size for it.

Sources

Primary sources used for this article (checked 11 October 2026):

• Wazuh documentation: Quickstart and hardware requirements
• AWS: Choosing the number of shards (OpenSearch Service)
• AWS: Calculating storage requirements (OpenSearch Service)
• CERT-In: Directions under section 70B(6), 28 April 2022

Frequently Asked Questions