As Wazuh deployments grow from a few hundred monitored endpoints to thousands of servers, workstations, cloud workloads, containers, and network devices, OpenSearch quickly becomes one of the most critical components of the entire security platform. Every alert generated by Wazuh is ultimately indexed in OpenSearch, making its performance directly responsible for search speed, dashboard responsiveness, threat hunting efficiency, and long-term data retention.

One of the biggest factors influencing OpenSearch performance is shard allocation.

Poor shard allocation can leave some nodes overloaded while others remain underutilized, causing slow searches, excessive JVM memory consumption, long recovery times, and unstable cluster health.

A well-designed shard allocation strategy distributes data evenly across the cluster, improves resilience, and ensures that Wazuh continues performing efficiently as data volumes increase.

Organizations often discover that simply adding more hardware does not solve performance problems. Without an intentional shard strategy, additional nodes may provide little benefit because data distribution remains uneven.

Understanding how OpenSearch allocates primary and replica shards is therefore essential for building scalable Wazuh environments.

In this guide, you’ll learn:

• How OpenSearch fits into the Wazuh architecture
• How shards and replicas work internally
• Which infrastructure components influence shard allocation
• Best practices for designing shard layouts for small, medium, and enterprise deployments
• Common shard allocation problems and how to avoid them
• How to monitor, optimize, and rebalance shard allocation as your environment grows

Understanding these concepts will help you build a faster, more resilient Wazuh deployment capable of handling increasing volumes of security telemetry while maintaining consistent search performance.

Understanding Wazuh OpenSearch Architecture

Before designing an effective shard allocation strategy, it’s important to understand how OpenSearch functions within a Wazuh deployment.

Shards do not exist in isolation, they store the security data generated by Wazuh, and their allocation directly affects every stage of alert indexing and retrieval.

What Is OpenSearch in Wazuh?

OpenSearch serves as Wazuh’s search and analytics engine.

It stores every indexed security event, making alerts searchable through the Wazuh Dashboard and available for dashboards, visualizations, threat hunting, compliance reporting, and forensic investigations.

Rather than keeping alerts inside the Wazuh Manager, the manager forwards processed events to OpenSearch through Filebeat.

OpenSearch then indexes the data into one or more indices, which are divided into shards and distributed across cluster nodes.

This architecture separates security event processing from data storage, allowing each component to scale independently.

Related Guide: How to Build a Wazuh Indexer Cluster

OpenSearch’s Role in Storing Alerts

Every detection generated by Wazuh eventually becomes a searchable document inside OpenSearch.

Examples include:

• Authentication failures
• Malware detections
• File Integrity Monitoring (FIM) events
• Vulnerability scan results
• Cloud audit logs
• Windows Event Logs
• Linux audit events
• Network intrusion alerts
• Compliance scan results

Instead of storing everything in one massive database, OpenSearch organizes these documents into indices, which are then divided into primary and replica shards.

This distributed architecture enables OpenSearch to index millions, or even billions, of security events while maintaining fast search performance.

Security Events and Indexed Data

Each indexed document contains structured fields that allow analysts to search efficiently.

Common indexed fields include:

• Timestamp
• Agent ID
• Hostname
• Rule ID
• Rule level
• Event category
• Decoder
• Source IP
• Destination IP
• Username
• MITRE ATT&CK mappings
• File paths
• Process names
• Hashes

Because every field becomes searchable, OpenSearch can quickly answer queries such as:

• Show all failed SSH logins
• Find malware alerts from the past 24 hours
• Search for PowerShell execution
• Display ransomware-related events
• Identify vulnerable hosts

The efficiency of these searches depends heavily on how data is distributed across shards.

Relationship Between Wazuh Manager, Filebeat, and OpenSearch

The Wazuh ecosystem consists of several independent services that work together.

The Wazuh Manager receives logs from agents, decodes events, evaluates rules, generates alerts, and performs active responses.

Filebeat collects generated alerts from the manager and securely forwards them to OpenSearch.

OpenSearch indexes those alerts and stores them for querying.

Finally, the Wazuh Dashboard retrieves indexed data from OpenSearch to display dashboards, visualizations, alerts, and search results.

This separation allows organizations to independently scale managers, indexers, and dashboards as data volumes increase.

Related Guide: Wazuh Filebeat: A Step-by-Step Setup Guide

How Data Flows Through Wazuh

Understanding the complete data flow helps explain why shard allocation directly impacts dashboard responsiveness and indexing throughput.

Agent → Manager

Wazuh agents continuously collect security information from monitored endpoints.

Examples include:

• Windows Event Logs
• Linux audit logs
• Syslog
• Application logs
• File integrity changes
• Registry modifications
• Vulnerability scan data

Agents securely transmit this information to the Wazuh Manager using encrypted communications.

Manager → Filebeat

After receiving events, the Wazuh Manager:

• Decodes incoming logs
• Matches detection rules
• Generates alerts
• Enriches event metadata
• Writes alerts to local JSON files

Filebeat monitors these alert files and prepares them for indexing.

Filebeat → OpenSearch

Also, Filebeat sends alerts to OpenSearch using the Bulk API, which indexes multiple documents in a single request for improved performance.

Large environments may process thousands of alerts per second. OpenSearch distributes incoming documents across primary shards according to the index’s routing algorithm.

Efficient shard allocation ensures indexing workloads remain balanced across all data nodes.

Dashboard Queries

When analysts search for alerts in the Wazuh Dashboard:

1. The dashboard sends a query to OpenSearch.
2. OpenSearch identifies which shards contain matching documents.
3. Multiple nodes execute the search simultaneously.
4. Results are aggregated.
5. The final response is returned to the dashboard.

Because queries execute in parallel across shards, balanced shard allocation significantly reduces response times.

Components That Affect Shard Allocation

Several OpenSearch components influence where shards are placed and how efficiently they operate.

Cluster Manager Nodes

Cluster Manager nodes (formerly called master nodes) manage the overall health and state of the OpenSearch cluster.

Responsibilities include:

• Maintaining cluster metadata
• Managing shard allocation
• Electing cluster managers
• Detecting failed nodes
• Coordinating shard recovery
• Monitoring cluster health

They do not normally store indexed data but make the decisions about where shards should reside.

Data Nodes

Data nodes are responsible for:

• Storing shards
• Indexing alerts
• Executing search queries
• Handling aggregations
• Managing replica synchronization

These nodes perform most of the computational work in large Wazuh environments.

As clusters grow, the number of data nodes usually determines overall indexing capacity.

Coordinating Nodes

Coordinating nodes receive client requests and distribute searches to the appropriate data nodes.

They:

• Route queries
• Merge search results
• Reduce client workload
• Improve scalability in large deployments

Dedicated coordinating nodes become increasingly valuable in enterprise-scale Wazuh environments with many concurrent dashboard users.

Ingest Nodes

Ingest nodes execute preprocessing pipelines before documents are indexed.

These pipelines may:

• Enrich documents
• Transform fields
• Normalize timestamps
• Add metadata
• Perform geolocation lookups

Offloading preprocessing from data nodes can improve indexing performance in high-volume environments.

Dashboards

Although the Wazuh Dashboard does not participate directly in shard allocation, it is often the first component where poor allocation becomes visible.

Symptoms include:

• Slow searches
• Delayed dashboards
• Timeout errors
• High query latency
• Missing visualizations during node failures

Many dashboard performance issues actually originate from inefficient shard placement within the OpenSearch cluster.

Related Guide: The Complete Wazuh Cluster Architecture Guide

Understanding OpenSearch Shards

Shard allocation only makes sense once you understand what shards actually are.

OpenSearch was designed to distribute enormous datasets across multiple servers instead of relying on a single machine.

It accomplishes this by dividing every index into smaller pieces called shards, allowing indexing and searching to occur in parallel.

A well-designed shard strategy improves scalability, resilience, and query performance, while a poor strategy can create bottlenecks that affect the entire Wazuh deployment.

What Is a Primary Shard?

A primary shard is the original partition of an OpenSearch index.

When an index is created, OpenSearch divides it into one or more primary shards.

Each document is stored in exactly one primary shard based on OpenSearch’s routing algorithm.

For example, an index with five primary shards distributes incoming alerts across those five partitions instead of storing everything together.

Primary shards:

• Store original indexed documents
• Handle indexing operations
• Process update requests
• Accept delete operations
• Serve search requests

The number of primary shards is fixed when an index is created and cannot be changed later without reindexing.

What Is a Replica Shard?

Replica shards are exact copies of primary shards.

If an index contains:

• 5 primary shards
• 1 replica

OpenSearch creates ten total shards.

Replicas provide:

• High availability
• Fault tolerance
• Additional query capacity
• Faster search performance under heavy load

Should a data node fail, OpenSearch automatically promotes an available replica to become the new primary shard, allowing the cluster to continue operating with minimal interruption.

How Shards Improve Performance

Instead of requiring a single server to process every indexing operation, OpenSearch distributes documents across multiple shards.

This enables:

• Parallel indexing
• Parallel searches
• Better CPU utilization
• Higher indexing throughput
• Improved scalability

As additional data nodes are added to the cluster, shards can be distributed among them, allowing indexing capacity to grow horizontally rather than relying solely on larger hardware.

According to the OpenSearch documentation, distributing indices across multiple shards enables clusters to scale well beyond the storage and compute limits of a single server while maintaining efficient query performance.

How Replicas Improve Availability

Replica shards protect against hardware failures and improve cluster resilience.

If a node hosting a primary shard becomes unavailable:

1. OpenSearch detects the failure.
2. A replica is promoted to primary.
3. Cluster operations continue.
4. A new replica is created when capacity becomes available.

This automatic failover minimizes downtime and helps maintain search availability during infrastructure failures.

How Queries Are Distributed

When a user searches from the Wazuh Dashboard, OpenSearch does not search one database.

Instead:

1. The query is sent to a coordinating node.
2. The coordinating node identifies relevant shards.
3. Each shard performs its portion of the search simultaneously.
4. Partial results are merged.
5. The final ranked results are returned.

Because searches execute in parallel, properly balanced shards often provide significantly faster response times than a single large database partition.

Shard Recovery Process

Shard recovery occurs whenever shards must be relocated or recreated.

Common recovery scenarios include:

• Node failures
• Cluster restarts
• Adding new nodes
• Removing nodes
• Rebalancing data
• Restoring snapshots

During recovery, OpenSearch copies shard data between nodes while keeping the cluster operational.

Recovery speed depends on several factors, including shard size, network bandwidth, disk performance, and available system resources.

Oversized shards can dramatically increase recovery times because more data must be transferred before the cluster returns to a healthy state. Conversely, excessively small shards create unnecessary overhead and can reduce overall cluster efficiency.

Designing an appropriate shard size is therefore a key part of an effective Wazuh OpenSearch strategy.

Related Guide: How to Build a Wazuh Indexer Cluster

Why Shard Allocation Matters in Wazuh

Shard allocation is much more than an OpenSearch configuration setting, it directly affects how efficiently Wazuh ingests alerts, executes searches, recovers from failures, and scales over time.

Every security event generated by your Wazuh deployment is written to a shard, meaning poor shard distribution can impact nearly every aspect of your security operations.

As organizations monitor more endpoints, cloud services, applications, and network devices, properly allocating shards becomes essential for maintaining a responsive and resilient OpenSearch cluster.

Large Alert Volumes

Modern Wazuh deployments generate enormous amounts of telemetry.

Sources may include:

• Windows Event Logs
• Linux audit logs
• Authentication events
• CloudTrail logs
• Kubernetes logs
• Firewall events
• IDS/IPS alerts
• File Integrity Monitoring (FIM)
• Vulnerability scan results
• Active Response events

A deployment monitoring 10,000 endpoints can easily produce millions of indexed documents every day.

Without an effective shard allocation strategy, incoming indexing requests may become concentrated on only a few data nodes, creating CPU bottlenecks, excessive disk I/O, and indexing delays.

By distributing primary shards evenly across the cluster, OpenSearch spreads indexing operations among multiple servers, significantly improving throughput during periods of high activity.

Related Guide: Step-by-Step Wazuh Manager Scaling Guide

Search Performance

Fast searches are critical during security investigations.

When analysts investigate suspicious activity, they expect queries to return results within seconds, not minutes.

Proper shard allocation improves search performance by:

• Distributing searches across multiple nodes
• Reducing hotspots
• Increasing query parallelism
• Balancing CPU utilization
• Minimizing disk contention

However, having either too many or too few shards can negatively affect performance.

Too many shards increase coordination overhead because each search must contact additional shard copies.

Too few shards reduce parallelism and concentrate workload onto fewer servers.

An effective strategy balances both indexing efficiency and search performance.

According to OpenSearch documentation, search requests execute in parallel across shards before being merged into a final response, making balanced shard distribution a key factor in query performance.

Cluster Stability

Poor shard allocation often leads to unstable clusters.

Common symptoms include:

• Yellow cluster status
• Red cluster status
• Uneven node utilization
• Frequent shard relocations
• JVM memory pressure
• Long garbage collection pauses
• Slow cluster state updates

Clusters experiencing continuous shard movement may spend significant resources relocating data instead of processing new alerts.

Designing shard allocation carefully from the beginning helps minimize unnecessary cluster rebalancing and reduces operational overhead.

Related Guide: How to Fix a Yellow Cluster Status in Wazuh Indexer

Hardware Utilization

One of the primary goals of shard allocation is maximizing the value of your infrastructure.

A poorly balanced cluster might look like this:

Although sufficient hardware exists, only one node is performing most of the work.

Balanced shard allocation distributes:

• CPU usage
• Disk I/O
• Memory utilization
• Search requests
• Indexing operations
• Network traffic

As a result, organizations can often improve performance without purchasing additional servers simply by optimizing shard placement.

High Availability

Security monitoring systems must remain available even during infrastructure failures.

Replica shards allow OpenSearch to continue serving queries when a node becomes unavailable.

If a server hosting a primary shard fails:

1. OpenSearch detects the outage.
2. A replica is promoted to primary.
3. Searches continue.
4. Indexing resumes.
5. A replacement replica is created once resources become available.

Without replica shards, or with poor shard allocation, a single hardware failure may leave indices unavailable until recovery completes.

For production Wazuh deployments, distributing replica shards across different physical or virtual hosts is a fundamental high-availability practice.

Disaster Recovery

Shard allocation also influences disaster recovery capabilities.

When nodes fail, clusters restart, or infrastructure is replaced, OpenSearch must recover affected shards before the cluster returns to a healthy state.

Several factors determine recovery speed, including:

• Shard size
• Number of shards
• Network bandwidth
• Storage performance
• Available CPU resources

Oversized shards can significantly delay recovery because large volumes of data must be copied before replicas become active.

Conversely, an excessive number of tiny shards increases metadata overhead and prolongs cluster coordination.

Designing appropriately sized shards therefore improves both day-to-day performance and recovery after failures.

Organizations should also incorporate regular snapshots into their disaster recovery strategy to protect against catastrophic failures.

Planning Your Shard Allocation Strategy

Effective shard allocation begins long before an OpenSearch cluster is deployed.

Rather than choosing an arbitrary number of shards, administrators should estimate expected workloads, storage requirements, retention policies, and future growth.

Proper capacity planning reduces the need for disruptive reindexing operations and helps ensure the cluster remains performant as the environment expands.

Estimate Daily Security Event Volume

The first step is understanding how much data your Wazuh deployment generates each day.

Factors that influence daily event volume include:

• Number of monitored endpoints
• Operating systems
• Installed integrations
• Active detection rules
• File Integrity Monitoring frequency
• Vulnerability scanning schedules
• Cloud service integrations
• Network device logging
• Application logging verbosity

For example:

Measuring actual event volume before scaling helps avoid overestimating or underestimating storage needs.

Calculate Expected Index Size

Alert count alone isn’t enough.

You also need to estimate how much disk space those alerts consume once indexed.

Index size depends on:

• Document size
• Number of indexed fields
• Replicas
• Compression
• Mapping configuration
• Stored metadata

A useful planning formula is:

Daily indexed data × retention period × (1 + replica factor)

For example:

• 150 GB/day
• 90-day retention
• One replica

Estimated storage:

150 × 90 × 2 = 27 TB

This calculation provides a baseline before accounting for operating system overhead, snapshots, or future expansion.

Determine Retention Period

Retention policies directly influence shard allocation.

Organizations commonly retain security data for:

• 30 days
• 90 days
• 180 days
• One year
• Multiple years for regulatory compliance

Longer retention periods increase:

• Total storage requirements
• Number of indices
• Total shard count
• Snapshot sizes

Instead of placing all historical data into one massive index, most Wazuh deployments use daily or monthly indices combined with lifecycle management policies.

Related Guide: How to Configure Wazuh Log Retention

Estimate Future Growth

One of the most common planning mistakes is sizing the cluster only for today’s workload.

Consider future changes such as:

• Additional endpoints
• Cloud migrations
• New business acquisitions
• Expanded compliance requirements
• Increased logging levels
• Additional integrations
• Security operations center growth

Planning for growth reduces the likelihood of costly reindexing projects as data volumes increase.

A common recommendation is to reserve additional storage and compute capacity beyond current requirements so clusters can absorb unexpected growth without immediate hardware upgrades.

Choose Appropriate Shard Sizes

Shard size has a significant impact on OpenSearch performance.

Very small shards increase metadata and cluster management overhead.

Very large shards take longer to relocate, recover, and rebalance after failures.

Many OpenSearch practitioners recommend targeting shard sizes in the 10 GB to 50 GB range for general-purpose workloads, though the optimal size depends on hardware, indexing rates, query patterns, and operational requirements.

The OpenSearch project recommends validating shard sizing with benchmarking rather than relying on fixed numbers, as every workload behaves differently.

Avoid Over-Sharding

Over-sharding occurs when an index contains far more shards than necessary.

Common consequences include:

• Increased heap usage
• Larger cluster state metadata
• Slower searches
• More shard relocations
• Longer cluster startup times
• Higher CPU consumption

Many small shards are generally less efficient than fewer appropriately sized shards.

Avoid Under-Sharding

Under-sharding creates the opposite problem.

Too few shards can result in:

• Uneven workload distribution
• Reduced indexing throughput
• CPU bottlenecks
• Larger recovery operations
• Limited scalability

For example, a single primary shard cannot utilize multiple data nodes simultaneously for indexing, even if additional servers are available.

The goal is to create enough shards to distribute work efficiently without creating unnecessary management overhead.

Choosing the Right Number of Primary Shards

Selecting the number of primary shards is one of the most important design decisions in OpenSearch because it determines how data is partitioned across the cluster.

Since primary shard counts cannot be changed after index creation without reindexing, administrators should make this decision carefully.

The ideal number depends on expected data volume, node count, growth projections, and search workloads rather than following a universal formula.

Small Deployments

Small environments typically include:

• Fewer than 500 endpoints
• One to three OpenSearch data nodes
• Relatively low daily alert volumes

For these deployments:

• One to three primary shards per daily index are often sufficient.
• One replica usually provides adequate fault tolerance.
• Simpler shard layouts reduce management overhead and conserve JVM heap.

The focus should be on maintaining healthy shard sizes rather than maximizing parallelism.

Medium Deployments

Medium-sized organizations often monitor:

• Hundreds to several thousand endpoints
• Multiple Wazuh Managers
• Dedicated OpenSearch clusters

These environments benefit from:

• Enough primary shards to utilize all available data nodes.
• Even shard distribution across the cluster.
• Capacity for future growth without immediate reindexing.

Periodic reviews of shard utilization help ensure that the original design continues to match operational demands as logging volumes increase.

Large Enterprise Deployments

Large enterprise environments commonly process:

• Tens of thousands of endpoints
• Billions of indexed documents
• Multiple terabytes of data per day
• Continuous security monitoring across multiple regions

These deployments typically require:

• Multiple dedicated data nodes
• Dedicated cluster manager nodes
• Coordinating nodes for search traffic
• Ingest nodes for preprocessing
• Tiered storage strategies for hot and warm data

Rather than relying on a single large index, organizations frequently distribute workloads across time-based indices and use Index State Management (ISM) policies to automate data lifecycle management.

Multi-Tenant Environments

Service providers and large enterprises often operate shared OpenSearch clusters that support multiple business units, customers, or environments.

In these scenarios, shard planning should account for:

• Tenant isolation
• Uneven ingestion rates
• Separate retention requirements
• Security boundaries
• Resource contention

Administrators may choose dedicated indices, or even dedicated node tiers, for high-volume tenants to prevent one workload from negatively impacting others.

Scaling Considerations

Shard allocation is not a one-time task.

As your Wazuh deployment evolves, your strategy should evolve with it.

Regularly monitor metrics such as:

• Shard size
• Shard count per node
• JVM heap utilization
• CPU usage
• Disk utilization
• Search latency
• Indexing throughput
• Shard relocation frequency

Capacity planning should become part of routine cluster maintenance, allowing you to rebalance workloads or expand infrastructure before performance degrades.

Related Guides:

• The Complete Wazuh Cluster Architecture Guide
• Step-by-Step Wazuh Manager Scaling Guide

Configuring Replica Shards

While primary shards determine how your data is partitioned, replica shards determine how resilient and scalable your OpenSearch cluster is.

Every replica is an exact copy of a primary shard and can serve search requests while providing redundancy if a data node fails.

Choosing the right replica configuration requires balancing availability, storage costs, indexing performance, and search workloads.

Too few replicas increase the risk of downtime, while too many consume additional storage and increase indexing overhead because every write operation must also be replicated.

Replica Recommendations

The optimal number of replica shards depends on your deployment size and availability requirements.

General recommendations include:

Keep in mind that every replica consumes approximately the same amount of storage as its corresponding primary shard.

For example:

• 5 primary shards
• 1 replica

Results in:

• 10 total shards
• Roughly double the storage requirements

Before increasing replica counts, ensure sufficient disk capacity exists across the cluster.

Single-Node Clusters

Replica shards provide no benefit in a single-node deployment.

Since replicas cannot be allocated to the same node as their primary shard, OpenSearch leaves replica shards unassigned when only one data node exists.

This results in a yellow cluster status, even though the system is functioning as expected.

For development, testing, and lab environments, configuring zero replicas avoids unnecessary warnings and conserves storage.

As soon as additional data nodes are introduced, replicas should be enabled to improve fault tolerance.

High Availability Clusters

Production Wazuh environments should always use replica shards.

When one data node fails:

1. OpenSearch detects the failure.
2. A replica shard is promoted to the new primary.
3. Search requests continue.
4. Indexing resumes.
5. Replacement replicas are created when sufficient capacity becomes available.

This automatic failover minimizes service interruptions during hardware failures, maintenance windows, or unexpected outages.

To maximize resilience, replica shards should never reside on the same physical server, rack, or availability zone as their corresponding primary shards.

Read Performance Benefits

Replica shards do more than improve availability, they also increase search capacity.

OpenSearch distributes search requests across both primary and replica shards, allowing multiple nodes to process queries simultaneously.

Benefits include:

• Faster dashboard loading
• Lower search latency
• Better support for concurrent users
• Improved reporting performance
• Reduced CPU pressure on individual data nodes

This becomes particularly valuable in Security Operations Centers (SOCs), where multiple analysts may perform complex threat-hunting queries at the same time.

However, replicas do not improve indexing speed because every new document must first be written to the primary shard before being replicated.

Replica Recovery

Whenever a node rejoins the cluster or new hardware is added, OpenSearch begins replica recovery.

During recovery, the cluster:

• Identifies missing replicas
• Copies shard data between nodes
• Verifies shard consistency
• Restores redundancy
• Rebalances the cluster if necessary

Recovery speed depends on several factors, including:

• Network bandwidth
• Storage performance
• Shard size
• CPU availability
• Number of recovering shards

Smaller, well-balanced shards generally recover much faster than oversized shards, reducing the time the cluster operates with reduced redundancy.

Administrators should monitor recovery operations after planned maintenance or unexpected outages to ensure all replicas return to an active state before considering the cluster fully healthy.

Understanding Allocation Awareness

By default, OpenSearch distributes shards across available data nodes to balance workload.

However, it has no inherent understanding of your physical infrastructure unless you explicitly provide that information.

Allocation awareness allows administrators to tell OpenSearch about the topology of the underlying environment, such as racks, hosts, or cloud availability zones, so that shard placement decisions improve resilience and reduce the risk of correlated failures.

Without allocation awareness, both a primary shard and its replica could unintentionally end up on infrastructure that shares the same failure domain.

Zone Awareness

Zone awareness distributes shards across multiple failure zones.

Examples include:

• Different data centers
• Different cloud regions
• Different availability zones
• Separate physical facilities

If an entire zone becomes unavailable because of a network outage, power failure, or maintenance event, replica shards located in another zone can continue serving requests.

Zone awareness is especially important for organizations operating geographically distributed Wazuh deployments.

Rack Awareness

Many on-premises environments organize servers into multiple racks.

Although servers occupy different machines, they may still share:

• Power distribution units
• Network switches
• Cooling infrastructure
• Top-of-rack networking

Rack awareness prevents OpenSearch from placing both primary and replica shards within the same rack whenever possible.

This reduces the impact of failures affecting shared rack infrastructure.

Host Awareness

Virtualized environments often run several OpenSearch nodes on the same physical host.

Without host awareness, OpenSearch may allocate:

• Primary shard → Virtual Machine A
• Replica shard → Virtual Machine B

Although these appear to be different nodes, both depend on the same physical server.

If that host fails, both copies of the shard become unavailable.

Host awareness ensures that shard copies are distributed across separate physical hosts, improving fault tolerance in VMware, Hyper-V, KVM, and similar virtualization platforms.

Availability Zones

Public cloud deployments commonly span multiple availability zones (AZs).

Cloud providers design availability zones with independent:

• Power
• Networking
• Cooling
• Physical facilities

Distributing primary and replica shards across multiple AZs protects the cluster from localized failures while maintaining low network latency between nodes.

For production cloud deployments, this architecture is generally considered a best practice.

Preventing Single Points of Failure

The primary objective of allocation awareness is eliminating single points of failure.

Without proper awareness, infrastructure failures can simultaneously affect both primary and replica shards.

Examples include:

• Entire rack failures
• Hypervisor failures
• Availability zone outages
• Storage array failures
• Network switch failures

Proper allocation awareness ensures that redundant shard copies remain available even when an entire failure domain is lost.

Combined with regular snapshots and replica shards, allocation awareness forms one of the most important layers of a resilient Wazuh OpenSearch architecture.

Related Guides: The Complete Wazuh Cluster Architecture Guide

Node Roles in Wazuh OpenSearch

OpenSearch assigns specialized responsibilities to different nodes within a cluster.

While small environments often combine these roles on the same server, larger Wazuh deployments typically separate them to improve performance, scalability, and fault tolerance.

Understanding each node role helps administrators design clusters that efficiently handle indexing, searching, cluster management, and data ingestion as workloads grow.

Dedicated Cluster Manager Nodes

Cluster Manager nodes are responsible for maintaining the health and coordination of the cluster.

Their responsibilities include:

• Maintaining cluster state
• Managing shard allocation
• Electing the active cluster manager
• Detecting failed nodes
• Coordinating shard recovery
• Managing index metadata

Because these operations are essential for cluster stability, production deployments should avoid placing heavy indexing or search workloads on dedicated Cluster Manager nodes.

OpenSearch generally recommends deploying an odd number of dedicated Cluster Manager nodes, commonly three, to maintain quorum and support leader elections if one node becomes unavailable.

Dedicated Data Nodes

Data nodes perform the majority of the workload in a Wazuh deployment.

They are responsible for:

• Storing primary shards
• Storing replica shards
• Indexing incoming alerts
• Executing search queries
• Running aggregations
• Managing local storage

Most hardware resources in a production cluster are allocated to data nodes because they perform the CPU-, memory-, and disk-intensive operations required for indexing and searching security events.

As Wazuh environments grow, scaling usually involves adding additional data nodes rather than increasing the responsibilities of existing servers.

Coordinating Nodes

Coordinating nodes act as intelligent request routers.

They receive requests from clients, including the Wazuh Dashboard, and then:

• Determine which shards must participate
• Forward queries to the appropriate data nodes
• Collect partial results
• Merge responses
• Return final search results

Dedicated coordinating nodes reduce the processing burden on data nodes and improve responsiveness during periods of heavy search activity.

They become particularly valuable in environments supporting numerous simultaneous dashboard users or automated reporting workloads.

Ingest Nodes

Ingest nodes preprocess documents before indexing.

Common ingest pipeline tasks include:

• Field transformations
• Metadata enrichment
• Timestamp normalization
• IP geolocation
• Data formatting
• Pipeline execution

Separating ingest processing from data nodes allows indexing operations to remain efficient, particularly when complex ingest pipelines are used.

Although many Wazuh deployments perform most processing before events reach OpenSearch, ingest nodes can still provide value for organizations implementing additional enrichment within OpenSearch.

Mixed-Role Nodes

Small and medium-sized deployments often combine several node roles on the same server.

For example, a single node may function as:

• Cluster Manager
• Data node
• Ingest node
• Coordinating node

This approach reduces hardware requirements and simplifies administration.

However, mixed-role nodes compete for the same CPU, memory, and storage resources.

As indexing rates and query volumes increase, this shared workload can become a limiting factor.

Mixed-role configurations are well suited to development environments, proof-of-concept deployments, and smaller production clusters with modest workloads.

When to Separate Node Roles

As a Wazuh deployment grows, separating node roles becomes increasingly beneficial.

Consider dedicated roles when you experience:

• High CPU utilization on data nodes
• Slow dashboard queries
• Long indexing delays
• Frequent garbage collection pauses
• Large cluster state updates
• Heavy concurrent search traffic
• Increasing shard counts
• Growing numbers of monitored endpoints

A typical progression is:

1. Start with mixed-role nodes for smaller environments.
2. Introduce dedicated Cluster Manager nodes as the cluster expands.
3. Scale horizontally by adding dedicated data nodes.
4. Add coordinating and ingest nodes when indexing and query workloads justify the additional infrastructure.

This layered architecture improves performance, simplifies scaling, and reduces the likelihood that one type of workload will negatively affect another.

Related Guides:

• How to Build a Wazuh Indexer Cluster
•  Step-by-Step Wazuh Manager Scaling Guide

Hot-Warm-Cold Architecture

As Wazuh deployments retain increasing amounts of security data, storing every index on high-performance hardware becomes both expensive and unnecessary.

Most organizations access recent alerts frequently, while older security events are rarely queried except during audits or incident investigations.

A Hot-Warm-Cold architecture addresses this challenge by placing data on different storage tiers based on its age and usage.

Recent indices remain on fast hardware for maximum performance, while older indices are automatically moved to less expensive storage without sacrificing accessibility.

This tiered approach reduces infrastructure costs while maintaining excellent search performance for the data analysts use most often.

Hot Nodes

Hot nodes store the most recently indexed security events.

These nodes handle:

• Continuous indexing
• Active search requests
• Dashboard queries
• Alert generation
• Threat hunting
• High write throughput

Because they process the majority of indexing operations, hot nodes typically use:

• High-performance SSD or NVMe storage
• Fast CPUs
• Large memory allocations
• High-speed networking

Typical data stored on hot nodes includes:

• Today’s alerts
• Recent incident investigations
• Active compliance monitoring
• Frequently accessed indices

Since hot nodes experience the highest workload, they should be monitored closely for CPU utilization, JVM heap usage, and disk I/O.

Warm Nodes

Warm nodes store data that is no longer actively written but is still searched regularly.

Examples include:

• Alerts from the previous month
• Compliance reports
• Historical investigations
• Security trend analysis

Warm nodes generally require:

• Moderate CPU resources
• Larger storage capacity
• Less expensive disks than hot nodes
• Lower indexing performance

Because indices stored on warm nodes are read-only, they generate significantly less write activity while remaining available for searches.

Moving older indices to warm nodes helps keep hot storage focused on current security operations.

Cold Nodes

Cold nodes store historical data that is rarely accessed.

Typical examples include:

• Archived security logs
• Regulatory retention data
• Long-term forensic evidence
• Older audit records

Cold storage prioritizes capacity and cost efficiency over search performance.

Organizations often use:

• Large-capacity HDDs
• Slower cloud storage
• Lower-cost storage tiers

Although searches on cold data are generally slower, the savings in storage costs can be substantial for environments retaining data for multiple years.

Frozen Storage (Optional)

Some organizations extend the architecture further by using frozen or archive storage for infrequently accessed data.

Frozen storage is appropriate for:

• Regulatory compliance
• Legal discovery
• Long-term audit requirements
• Historical investigations

Characteristics include:

• Lowest storage costs
• Long retrieval times
• Minimal infrastructure requirements
• Rare search activity

Not every Wazuh deployment requires this tier, but organizations with strict retention requirements may benefit from archiving older indices outside the primary OpenSearch cluster while maintaining recoverability through snapshots and external storage.

Index Lifecycle Management (ISM)

Manually moving hundreds or thousands of indices between storage tiers quickly becomes impractical.

OpenSearch provides Index State Management (ISM) to automate the lifecycle of indices.

Typical ISM workflows include:

1. Create a new index.
2. Store it on hot nodes.
3. Move it to warm nodes after 30 days.
4. Move it to cold storage after 90 days.
5. Delete or archive it after the retention period expires.

Policies can also automate:

• Force merges
• Replica changes
• Read-only transitions
• Snapshot creation
• Index deletion

Automating these tasks reduces administrative effort while ensuring storage resources are used efficiently.

When Tiered Storage Makes Sense

Not every Wazuh deployment requires multiple storage tiers.

Tiered storage is generally beneficial when organizations:

• Retain security data for several months or years.
• Process hundreds of gigabytes or terabytes of data daily.
• Need to reduce infrastructure costs.
• Must satisfy regulatory retention requirements.
• Operate large Security Operations Centers (SOCs).
• Require rapid searches for recent data while preserving historical records.

Smaller deployments with short retention periods may achieve excellent performance using only hot storage.

As data volumes grow, introducing warm and cold tiers provides a cost-effective path to scaling without sacrificing operational efficiency.

Related Guide: How to Configure Wazuh Log Retention

Index Templates and Shard Configuration

Creating indices manually is both inefficient and error-prone.

OpenSearch solves this problem through index templates, which automatically apply predefined settings whenever new indices are created.

For Wazuh deployments that generate new time-based indices daily, templates ensure consistent shard counts, replica settings, mappings, compression, and other configuration options across the cluster.

Without templates, inconsistent index configurations can lead to uneven shard allocation, unpredictable performance, and increased administrative overhead.

Creating Index Templates

Index templates define the settings and mappings that new indices inherit during creation.

A template can specify:

• Number of primary shards
• Number of replica shards
• Index mappings
• Compression options
• Refresh intervals
• Index aliases
• Index State Management (ISM) policies

Rather than configuring each index individually, administrators create one template that automatically applies to all matching Wazuh indices.

This simplifies cluster management and helps enforce consistent operational standards.

Default Shard Settings

One of the most important template settings is the default number of primary shards.

Administrators should select shard counts based on:

• Daily data volume
• Expected shard size
• Number of data nodes
• Future growth projections
• Search workload

Avoid selecting shard counts based solely on hardware availability today, as future expansion may require different allocation strategies.

Since changing the number of primary shards requires reindexing, careful planning at the template level can prevent disruptive maintenance later.

Replica Settings

Templates also define how many replica shards each index should maintain.

Different environments may use different defaults:

Administrators should periodically review replica settings as clusters expand or availability requirements change.

Increasing replica counts improves fault tolerance and search scalability but also increases storage consumption and replication traffic.

Compression Settings

Compression reduces the amount of disk space required to store indexed documents.

Benefits include:

• Lower storage costs
• Improved disk utilization
• Better cache efficiency
• Reduced backup sizes

The trade-off is additional CPU usage during compression and decompression.

For most Wazuh deployments, storage savings significantly outweigh the relatively small CPU overhead, especially when retaining large volumes of security data.

Administrators should benchmark compression performance against their specific workload before deploying changes broadly.

Refresh Interval

The refresh interval determines how quickly newly indexed documents become searchable.

Short refresh intervals provide:

• Near real-time visibility
• Faster alert searches
• More responsive dashboards

Longer refresh intervals can improve indexing throughput because OpenSearch performs refresh operations less frequently.

The ideal setting depends on operational priorities.

Organizations requiring immediate visibility into security events often prefer shorter intervals, while high-ingestion environments may increase the interval to maximize indexing performance during peak activity.

Index Naming Strategies

Consistent naming conventions simplify administration, automation, and lifecycle management.

Common approaches include:

• Daily indices
• Weekly indices
• Monthly indices
• Environment-specific prefixes
• Business-unit prefixes

Examples:

• wazuh-alerts-2026.07.24
• wazuh-alerts-prod-2026.07
• wazuh-cloud-2026.07.24

Effective naming conventions make it easier to:

• Apply ISM policies
• Perform backups
• Restore snapshots
• Manage retention
• Monitor cluster health

Organizations operating multiple environments should establish naming standards early to avoid future administrative complexity.

Related Guide: How to Backup Wazuh Manager Configuration

Balancing Shards Across Nodes

Even with an appropriate number of shards and replicas, poor distribution can leave some nodes overloaded while others remain underutilized.

Shard balancing is the process of distributing primary and replica shards evenly throughout the cluster so that storage, CPU, memory, and search workloads are shared as uniformly as possible.

A well-balanced cluster improves performance, increases resilience, and simplifies future scaling.

Automatic Allocation

OpenSearch automatically allocates shards whenever:

• A new index is created.
• A node joins the cluster.
• A node fails.
• Hardware is added.
• Indices are restored.
• Cluster topology changes.

The allocation engine considers factors such as:

• Available disk space
• Existing shard distribution
• Node availability
• Allocation awareness settings
• Replica placement rules

Automatic allocation is sufficient for most deployments and significantly reduces day-to-day administrative effort.

Manual Allocation

Although automatic allocation works well in most situations, administrators may occasionally need manual control.

Examples include:

• Isolating high-volume indices
• Testing new hardware
• Troubleshooting allocation issues
• Preparing infrastructure migrations
• Recovering from abnormal cluster conditions

Manual allocation should be used carefully because overriding OpenSearch’s allocation logic may create unintended workload imbalances.

In general, manual intervention is best reserved for exceptional operational scenarios rather than routine cluster management.

Cluster Rebalancing

As workloads change, OpenSearch continuously evaluates whether shards should be relocated to improve balance.

Rebalancing may occur after:

• Adding data nodes
• Removing servers
• Restoring snapshots
• Hardware failures
• Storage utilization changes
• Allocation rule updates

During rebalancing, shards are copied between nodes while the cluster remains operational.

Although this process is generally automatic, large shard movements consume network bandwidth, CPU resources, and disk I/O.

Scheduling infrastructure changes during periods of lower activity can reduce the impact of large-scale shard relocations.

Allocation Filters

Allocation filters allow administrators to control where specific indices or shards may reside.

Filters can use attributes such as:

• Node name
• Storage tier
• Hardware class
• Rack identifier
• Availability zone
• Custom node attributes

Common use cases include:

• Restricting hot indices to SSD-backed nodes
• Moving archived data to high-capacity storage
• Isolating workloads by environment
• Separating production and testing indices
• Supporting tiered storage architectures

Allocation filters provide fine-grained control while still allowing OpenSearch to automate balancing within the defined constraints.

Excluding Nodes During Maintenance

Planned maintenance often requires temporarily removing nodes from service without disrupting the cluster.

Before shutting down a node, administrators can configure allocation settings that instruct OpenSearch to relocate shards elsewhere.

Typical maintenance activities include:

• Operating system upgrades
• Hardware replacement
• Storage expansion
• Kernel updates
• Security patching

Excluding nodes before maintenance helps prevent unnecessary downtime and ensures that primary and replica shards remain available throughout the maintenance window.

After maintenance is complete, the node can be returned to the cluster, allowing OpenSearch to rebalance shards automatically.

Related Guides:

• How to Build a Wazuh Indexer Cluster
• The Complete Wazuh Cluster Architecture Guide

Troubleshooting Shard Allocation Issues