As organizations expand their infrastructure, a single Wazuh Manager can eventually become a bottleneck. More endpoints generate more security events, more log sources increase ingestion rates, and more analysts require continuous access to security data.

Without a scalable architecture, organizations may experience delayed alert processing, higher resource utilization, and reduced fault tolerance.

This is where Wazuh cluster architecture becomes essential.

Rather than relying on a single manager, Wazuh distributes workloads across multiple nodes while maintaining centralized management and synchronized configuration.

The result is a deployment that can handle significantly larger environments without sacrificing performance or availability.

Understanding how Wazuh’s clustered architecture works before deploying additional nodes helps administrators design an environment that is easier to manage, troubleshoot, and scale.

Instead of reacting to performance problems after they occur, teams can build an architecture that supports future growth from the beginning.

This guide explains every major component of the Wazuh cluster, how those components communicate, how data flows through the platform, and the architectural decisions that affect performance, resilience, and scalability.

You’ll also learn when clustering is appropriate, how each node contributes to the overall system, common deployment patterns, and the best practices used in enterprise environments.

This guide is designed for:

Security engineers deploying Wazuh in medium to large environments
SOC analysts who want to understand how alerts move through the platform
System administrators responsible for scaling Wazuh infrastructure
DevOps and infrastructure engineers designing highly available SIEM deployments
Organizations planning to migrate from a standalone Wazuh Manager to a clustered environment

Throughout this guide, we’ll also reference several in-depth tutorials covering cluster deployment, scaling, Filebeat configuration, database architecture, troubleshooting, and disaster recovery.

What Is a Wazuh Cluster?

A Wazuh cluster is a group of multiple Wazuh Manager nodes that work together as a single logical deployment.

Instead of having one server responsible for processing every agent event, the workload is distributed across several managers that communicate continuously to keep the environment synchronized.

At the center of the cluster is the master node, which coordinates cluster operations, synchronizes configuration files, manages agent metadata, and distributes information to one or more worker nodes.

Worker nodes handle much of the incoming agent traffic and event processing while remaining synchronized with the master.

In a traditional single-node deployment, one server performs every major function:

Agent communication
Rule evaluation
Decoder processing
Active response
Configuration management
File synchronization

This architecture works well for small environments but eventually reaches hardware limitations as the number of monitored endpoints increases.

A clustered deployment distributes those responsibilities across multiple servers, allowing organizations to monitor thousands, or even tens of thousands, of endpoints more efficiently.

Advantages of Clustering

Compared to a standalone installation, clustering provides several advantages:

Higher event processing capacity
Better resource utilization across multiple servers
Improved resilience if individual nodes become unavailable
Easier horizontal scaling
Simplified maintenance with reduced operational impact

Although clustering improves availability, it should not be confused with automatic disaster recovery.

Proper backups, external load balancing, and infrastructure redundancy are still required to eliminate single points of failure.

Related Guide: How to Set Up a Multi-Node Wazuh Cluster

Enterprise organizations commonly deploy clustered Wazuh environments in scenarios such as:

Monitoring thousands of Windows and Linux endpoints
Multi-site or geographically distributed environments
Large cloud infrastructures spanning multiple regions
Managed Security Service Providers (MSSPs) supporting multiple customers
Critical infrastructure environments requiring high uptime
Enterprises with large SOC teams operating around the clock

According to the NIST Computer Security Resource Center (SP 800-137), continuous security monitoring becomes increasingly important as organizations grow, requiring scalable monitoring infrastructures capable of processing large volumes of security telemetry across distributed environments.

Similarly, the MITRE ATT&CK framework emphasizes comprehensive visibility across endpoints, networks, and cloud infrastructure, something that scalable SIEM architectures are designed to support.

Core Components of Wazuh Cluster Architecture

A Wazuh cluster consists of several tightly integrated services, each responsible for a specific part of the security monitoring pipeline.

Understanding these components makes it much easier to design scalable deployments, troubleshoot issues, and optimize overall performance.

The most important component is the Wazuh Manager, which serves as the central processing engine for security events.

Wazuh Manager

The Wazuh Manager receives security data from enrolled agents, analyzes events using decoders and detection rules, generates alerts, coordinates active responses, and forwards processed alerts to downstream components such as Filebeat and the Wazuh Indexer.

In a clustered deployment, every manager performs event analysis locally while remaining synchronized with the rest of the cluster.

This distributed processing model allows organizations to increase capacity simply by adding additional worker nodes rather than upgrading a single server.

The Wazuh Manager is responsible for several core functions.

Responsibilities

The manager coordinates nearly every security operation performed within Wazuh, including:

Receiving events from agents
Parsing raw log data
Applying decoders
Matching detection rules
Executing active responses
Managing agent enrollment
Synchronizing cluster data
Maintaining internal databases
Communicating with Filebeat for alert forwarding

Because the manager performs CPU-intensive analysis, it is often the first component organizations scale when monitoring large numbers of endpoints.

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

Event Analysis

Every event received by the manager passes through multiple processing stages before an alert is generated.

A simplified workflow looks like this:

Agent sends an event.
The manager identifies the log format.
Appropriate decoders extract structured fields.
Detection rules evaluate the event.
Rule correlation occurs.
Severity is calculated.
Active response conditions are evaluated.
Alert is written to alerts.json.
Filebeat forwards the alert to the Wazuh Indexer.

This multi-stage pipeline enables Wazuh to detect everything from brute-force attacks and privilege escalation attempts to malware activity and policy violations.

The official Wazuh documentation provides a detailed overview of the manager’s analysis engine and event processing workflow.

Rule Processing

Rule processing is one of the most important responsibilities of the Wazuh Manager.

Each incoming event is evaluated against thousands of built-in detection rules contained within the Wazuh ruleset. These rules analyze:

Authentication failures
File integrity changes
Malware indicators
Privilege escalation attempts
Vulnerability detection
Compliance violations
Suspicious process activity
Cloud security events

Rules can also be customized to detect organization-specific threats.

Processing occurs locally on each manager node, allowing event analysis to scale horizontally as additional worker nodes are added.

Agent Management

The Wazuh Manager is also responsible for managing communication with enrolled agents.

This includes:

Agent registration
Authentication
Key management
Configuration synchronization
Heartbeat monitoring
Status reporting
Group assignments
Centralized configuration deployment

In clustered environments, agent metadata remains synchronized between nodes so that workers have consistent information regardless of where agents connect.

Proper agent management ensures that thousands of endpoints can be administered centrally while maintaining consistent configurations across the environment.

Industry experts consistently recommend separating management, indexing, and visualization tiers when scaling SIEM platforms.

This distributed architecture minimizes resource contention, improves resilience, and allows each layer to scale independently based on workload.

This aligns with architectural guidance from both the Wazuh project and broader distributed systems best practices.

Master Node

The master node is the central coordination point of a Wazuh cluster.

While it performs the same event analysis functions as any other Wazuh Manager, it also manages cluster-wide operations that keep every node synchronized and operating as a unified system.

It’s important to understand that the master is not responsible for processing every event in the cluster.

Worker nodes independently analyze events from their connected agents.

Instead, the master focuses on maintaining consistency across the deployment by coordinating configuration, cluster membership, and agent metadata.

In production environments, the master should be provisioned with sufficient CPU, memory, and storage to handle both event processing and cluster management tasks.

Primary Responsibilities

The master node oversees several critical cluster functions, including:

Maintaining cluster membership
Coordinating node synchronization
Managing agent registration information
Distributing configuration changes
Monitoring worker node health
Synchronizing shared files
Maintaining cluster integrity

Because every worker depends on the master for synchronization, it is considered one of the most critical components of the cluster architecture.

Configuration Synchronization

One of the master’s most important jobs is ensuring that configuration files remain identical across every manager in the cluster.

When administrators modify shared configuration files, the master distributes those changes to worker nodes automatically.

Examples of synchronized data include:

Shared rules
Decoders
Agent groups
Centralized configurations
Lists
Cluster metadata
Various internal configuration files

This centralized synchronization eliminates the need to manually update every server whenever rules or configurations change.

Agent Registration Management

The master maintains authoritative information about registered agents.

When new endpoints enroll into the environment, agent metadata is synchronized throughout the cluster so worker nodes can recognize and manage those agents consistently.

This synchronization includes:

Agent IDs
Authentication keys
Group assignments
Agent names
Registration status
Shared configuration information

Keeping this information synchronized ensures that administrators have a consistent view of managed endpoints regardless of which node they’re connected to.

Cluster Coordination

Beyond synchronization, the master continuously monitors cluster health.

Its coordination responsibilities include:

Detecting node availability
Monitoring synchronization status
Handling cluster membership changes
Managing communication between nodes
Recording synchronization events
Reporting cluster status

If communication issues occur, administrators can often identify synchronization problems through the cluster logs before they impact production workloads.

For synchronization problems, see our Fixing Wazuh Cluster Desync Caused by Master-Worker Time Drift guide.

Worker Nodes

Worker nodes perform the majority of the computational work in a large Wazuh deployment.

They receive events from connected agents, analyze logs, execute detection rules, and generate alerts independently.

Adding additional worker nodes allows organizations to scale horizontally without significantly changing the existing architecture.

Processing Agent Events

Each worker node performs the complete Wazuh analysis pipeline locally.

This includes:

Receiving agent events
Parsing logs
Running decoders
Matching rules
Triggering active responses
Writing alerts
Sending alerts through Filebeat

Because processing is distributed, workloads can be balanced across multiple servers rather than overwhelming a single manager.

Sharing Workload

Horizontal scaling is one of the primary benefits of clustering.

Instead of upgrading one increasingly powerful server, organizations can add worker nodes as event volume grows.

This approach provides several advantages:

Better CPU utilization
Reduced processing latency
Increased event throughput
Improved scalability
Easier maintenance windows

Large enterprise deployments commonly distribute tens of thousands of agents across multiple worker nodes.

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

Communication with the Master

Worker nodes continuously communicate with the master to remain synchronized.

They periodically exchange information such as:

Updated configuration files
Agent metadata
Cluster health information
Synchronization status
Shared rules
Decoder updates

Although workers process events independently, synchronization ensures they all behave consistently.

Failover Considerations

Worker nodes improve overall cluster resilience by distributing workloads, but they do not automatically eliminate every single point of failure.

For true high availability, organizations should also implement:

External load balancers
Redundant infrastructure
Backup master strategies
Regular configuration backups
Monitoring for node health
Disaster recovery planning

Clustering improves operational continuity, but it should be viewed as one component of a broader high-availability architecture rather than a complete failover solution.

Wazuh Indexer

The Wazuh Indexer is responsible for storing, indexing, and searching the alerts generated by Wazuh Managers.

Built on OpenSearch, it provides the scalable data storage layer that enables fast searches, dashboards, visualizations, and long-term retention.

Unlike the manager, the Indexer does not analyze security events. Its primary role begins after alerts have already been generated.

Storage Architecture

Alerts received from Filebeat are stored as indexed documents.

The Indexer organizes this information into indices that support:

Full-text searches
Structured queries
Aggregations
Historical analysis
Compliance reporting
Dashboard visualizations

Because data is indexed rather than stored as flat log files, analysts can quickly retrieve relevant security events from millions of records.

Search Capabilities

The Indexer enables powerful search functionality across security data.

Analysts can search by:

Agent
Hostname
Username
IP address
Rule ID
MITRE ATT&CK technique
File path
Event severity
Timestamp
Custom fields

These capabilities allow security teams to investigate incidents in seconds instead of manually reviewing raw log files.

Cluster Interaction

Managers do not communicate directly with the Indexer.

Instead, the workflow is:

Manager processes events.
Alerts are written locally.
Filebeat collects the alerts.
Filebeat securely forwards them to the Indexer.
The Dashboard retrieves indexed data through APIs.

This separation allows each layer of the architecture to scale independently.

Scaling Considerations

As alert volumes grow, the Indexer often becomes the largest infrastructure component.

Scaling considerations include:

Increasing storage capacity
Adding Indexer nodes
Configuring shard allocation
Replica management
Heap memory tuning
Index lifecycle management (ILM)
Snapshot strategies

OpenSearch recommends careful shard sizing and replica planning to maintain cluster performance as data volumes increase.

Related Guide: How to Build a Wazuh Indexer Cluster

Wazuh Dashboard

The Wazuh Dashboard provides the graphical interface used by analysts and administrators to monitor alerts, investigate incidents, manage agents, and configure the platform.

It serves as the presentation layer of the architecture rather than participating directly in event processing.

Visualization Layer

The Dashboard offers visual access to:

Security alerts
Compliance reports
Vulnerability findings
File integrity monitoring
Agent health
Threat intelligence
MITRE ATT&CK mappings
Inventory data

These visualizations enable security teams to identify trends and investigate incidents more efficiently.

API Communication

The Dashboard communicates primarily with the Wazuh API and the Wazuh Indexer.

Through these interfaces it can:

Retrieve indexed alerts
Display agent information
Manage users
Execute API requests
Display cluster health
Configure monitoring components

The separation between the Dashboard and processing components allows the user interface to remain responsive even during periods of heavy event ingestion.

Cluster Awareness

In clustered deployments, the Dashboard presents information from the entire environment rather than from a single manager.

Administrators can monitor:

Connected nodes
Cluster health
Agent status
Alert statistics
Index health
Manager performance

This centralized visibility greatly simplifies administration of large deployments.

Filebeat

Filebeat acts as the transport layer between the Wazuh Manager and the Wazuh Indexer.

Rather than sending alerts directly to the Indexer, managers write alerts to local files, which Filebeat continuously monitors and forwards.

This decoupled architecture improves reliability and simplifies scaling.

Shipping Alerts to the Indexer

Filebeat continuously watches Wazuh alert files and forwards new events to the Indexer.

Its responsibilities include:

Reading alerts.json
Buffering events
Compressing data
Retrying failed transmissions
Load balancing traffic
Maintaining delivery reliability

This buffering capability helps prevent temporary network interruptions from causing data loss.

TLS Communication

Communication between Filebeat and the Wazuh Indexer is typically secured using TLS encryption.

TLS provides:

Confidentiality
Integrity
Mutual authentication
Certificate validation
Protection against interception

Encrypting alert traffic is especially important when managers and Indexers reside on separate networks or cloud environments.

High-Availability Considerations

In enterprise deployments, Filebeat can be configured to support highly available Indexer clusters through:

Multiple output hosts
Automatic failover
Load balancing
Retry queues
Persistent buffering

Proper Filebeat configuration helps ensure alerts continue flowing even if individual Indexer nodes become temporarily unavailable.

For more information on filebeat, see our Wazuh Filebeat: A Step-by-Step Setup Guide.

Wazuh DB

Wazuh DB is an internal database service that stores operational information used by the Wazuh Manager.

Rather than functioning as a general-purpose database, it provides fast local access to agent and system metadata required during event processing.

Internal Database Architecture

Wazuh DB uses SQLite databases managed through the wazuh-db daemon.

These databases store information such as:

Agent metadata
File Integrity Monitoring data
Vulnerability information
Inventory records
Internal state information

Because SQLite is lightweight and file-based, it offers fast local access without requiring a separate database server.

Agent Database Management

Each monitored endpoint has its own database containing information relevant to that specific agent.

This design allows Wazuh to efficiently:

Update inventory data
Store FIM information
Track vulnerability results
Record software inventories
Manage agent-specific metadata

Distributing data across multiple databases improves performance and reduces contention during large-scale operations.

Communication with the Manager

The Wazuh Manager communicates with wazuh-db through Unix domain sockets instead of traditional network protocols.

This local communication method provides:

Low latency
Reduced overhead
Improved performance
Secure local communication

Because nearly every event requires metadata lookups, efficient communication between the manager and Wazuh DB is essential for maintaining high processing throughput.

Related Guide: Understanding the Wazuh DB Architecture

How Wazuh Cluster Communication Works

A Wazuh cluster functions because its components communicate continuously to exchange configuration data, agent metadata, processed alerts, and health information.

Understanding these communication paths helps administrators troubleshoot synchronization issues, optimize performance, and design resilient deployments.

Internal Cluster Protocol

Wazuh managers use an internal cluster protocol to exchange synchronization data between the master and worker nodes.

This protocol is responsible for:

Node discovery
Membership validation
File synchronization
Agent metadata updates
Cluster health monitoring
Status reporting

Unlike agent traffic, this communication occurs only between cluster members.

Secure Node Communication

Cluster communication should always occur over trusted networks and be protected using authentication and encryption mechanisms supported by Wazuh.

Security best practices include:

Isolating cluster traffic
Restricting firewall access
Using secure certificates where applicable
Limiting administrative access
Monitoring synchronization logs

The official Wazuh documentation provides detailed guidance on securing inter-node communication.

Cluster Ports

A typical clustered deployment uses dedicated ports for different communication paths, including:

Agent-to-manager communication
Cluster synchronization
Wazuh API access
Dashboard access
Filebeat-to-Indexer traffic
OpenSearch node communication

Using separate ports simplifies firewall management and network troubleshooting.

Authentication

Every participating component authenticates before exchanging sensitive information.

Authentication occurs between:

Agents and managers
Dashboard and API
Filebeat and Indexer
Cluster members

This layered approach helps prevent unauthorized systems from joining the monitoring infrastructure.

Configuration Synchronization

One of the defining characteristics of a Wazuh cluster is automatic synchronization of shared configuration.

What Files Are Synchronized

Examples include:

Rules
Decoders
Agent groups
Shared configurations
Lists
Cluster metadata

How Updates Propagate

When an administrator modifies synchronized files on the master node, those changes are propagated to worker nodes automatically, ensuring consistent behavior across the cluster.

Synchronization Intervals

Workers periodically check for updates from the master. This continuous synchronization helps ensure that new rules, decoders, and configurations become available across the environment without manual intervention.

Agent Communication Flow

Agent communication follows a well-defined path from endpoint to alert generation.

1. Agent Registration

New endpoints register with the manager using authentication keys and receive unique agent identifiers that are synchronized throughout the cluster.

2. Event Forwarding

After registration, agents continuously send security events to their assigned manager, where logs are decoded and analyzed.

3. Response Delivery

When detection rules trigger an active response, the manager securely delivers response instructions back to the originating agent.

Alert Processing Pipeline

Every security event follows a consistent processing pipeline.

Event Collection

Agents collect telemetry from operating systems, applications, network devices, cloud services, and security tools.

Decoding

Incoming logs are parsed into structured fields using Wazuh decoders.

Rule Matching

Decoded events are evaluated against the Wazuh ruleset and any custom detection rules.

Alert Generation

If a rule matches, the manager generates an alert with metadata such as severity, MITRE ATT&CK mappings, and contextual information.

Indexing

Finally, Filebeat forwards the alert to the Wazuh Indexer, where it becomes searchable through the Wazuh Dashboard for investigation, reporting, and long-term analysis.

Wazuh Cluster Topology

The ideal Wazuh cluster topology depends on the size of your environment, expected event volume, availability requirements, and future growth plans.

While smaller organizations can often operate efficiently with only a few nodes, enterprise deployments typically separate processing, storage, and visualization into dedicated clusters for maximum scalability.

Understanding common deployment patterns helps administrators choose an architecture that balances performance, resilience, and operational complexity.

Two-Node Architecture

A two-node deployment is often the first step organizations take when moving beyond a standalone Wazuh Manager.

A typical topology consists of:

One master node
One worker node
One or more Wazuh Indexer nodes
Wazuh Dashboard
Filebeat on each manager

The worker node shares event processing responsibilities while the master continues coordinating cluster synchronization.

Advantages

Simple deployment
Increased processing capacity
Easier maintenance
Lower infrastructure costs

Limitations

Limited fault tolerance
Master remains a critical dependency
Less suitable for very large environments

This architecture is commonly used by medium-sized organizations monitoring several thousand endpoints.

Three-Node Architecture

A three-node manager cluster provides additional processing capacity and improved workload distribution.

A common layout includes:

One master node
Two worker nodes
Dedicated Indexer cluster
Dashboard server
External load balancer

Incoming agent connections are distributed across the worker nodes while the master coordinates synchronization.

Benefits include:

Higher event throughput
Better CPU utilization
Reduced processing latency
Improved maintenance flexibility
Greater scalability

Many organizations supporting between 10,000 and 30,000 monitored endpoints adopt this topology before expanding further.

Large Enterprise Clusters

Enterprise deployments often separate every major architectural layer into independently scalable clusters.

A typical enterprise architecture may include:

Multiple worker managers
Dedicated master node
Three or more Wazuh Indexer nodes
Multiple Dashboard instances
External load balancers
Dedicated Filebeat instances
Centralized backup infrastructure
Monitoring and alerting systems

This separation allows each layer to scale according to its own workload rather than scaling the entire environment simultaneously.

Large financial institutions, government agencies, healthcare providers, and managed security service providers (MSSPs) frequently deploy architectures of this type to support tens of thousands of endpoints and continuous security monitoring.

Multi-Datacenter Deployments

Organizations operating across multiple geographic regions may distribute Wazuh infrastructure between data centers to improve resilience and reduce latency.

Typical deployment objectives include:

Regional agent connectivity
Geographic redundancy
Disaster recovery
Reduced WAN traffic
Compliance with data residency requirements

Design considerations include:

Network latency between sites
Bandwidth availability
Synchronization performance
Backup strategies
DNS and load balancing
Certificate management

Because cluster synchronization relies on continuous communication, administrators should carefully evaluate network reliability before stretching clusters across long-distance links.

The official Wazuh documentation recommends designing clusters with reliable, low-latency connectivity between participating nodes to maintain synchronization performance.

High Availability in Wazuh Clusters

Although clustering significantly improves scalability, achieving high availability (HA) requires more than simply adding additional manager nodes.

Every major component, including managers, Indexers, Dashboards, storage, and networking, should be designed with redundancy in mind.

A properly designed HA architecture minimizes downtime during hardware failures, maintenance windows, or unexpected outages.

Load Balancing

Load balancers distribute incoming traffic across multiple Wazuh Managers, preventing any single node from becoming overloaded.

Depending on the deployment, load balancers may distribute:

Agent connections
Dashboard traffic
API requests
Administrative access

Benefits include:

Better resource utilization
Improved response times
Higher availability
Easier maintenance
Simplified scaling

Organizations commonly use software solutions such as HAProxy or NGINX, as well as cloud-native load balancers, to distribute traffic across manager nodes.

Redundant Managers

Deploying multiple Wazuh Managers reduces dependence on any single processing server.

If one worker node becomes unavailable:

Other workers continue processing events.
Agents reconnect through the load balancer.
Alert generation continues with minimal interruption.

Although the master remains responsible for cluster coordination, distributing event processing across several workers significantly improves operational resilience.

Related Guide: How to Set Up a Multi-Node Wazuh Cluster

Indexer Redundancy

The Wazuh Indexer should also be deployed as a cluster rather than as a standalone server.

Multiple Indexer nodes provide:

Replica shards
Automatic data replication
Improved search performance
Better storage scalability
Increased fault tolerance

If one Indexer node fails, replicas stored on other nodes help maintain data availability while the cluster rebalances itself.

Proper shard allocation and replica configuration are essential for maintaining both performance and resilience.

Related Guide: How to Build a Wazuh Indexer Cluster

Dashboard Redundancy

The Wazuh Dashboard is often overlooked when designing highly available deployments.

Running multiple Dashboard instances behind a load balancer provides:

Improved administrator access
Reduced downtime
Maintenance flexibility
Higher availability during upgrades

Because the Dashboard primarily serves as the visualization layer, scaling multiple instances is generally straightforward.

Avoiding Single Points of Failure

True high availability requires identifying and eliminating every critical dependency that could interrupt monitoring.

Common single points of failure include:

One Wazuh Manager
One Indexer
One Dashboard
One load balancer
One storage device
One network path
One DNS server
One backup repository

Organizations should also implement:

Regular configuration backups
Automated monitoring
Health checks
Snapshot management
Disaster recovery testing

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) recommends building resilient architectures with redundancy and tested recovery procedures to maintain operational continuity during cyber incidents or infrastructure failures.

Scaling a Wazuh Cluster

As environments grow, security teams must ensure that the Wazuh infrastructure can continue processing events without introducing latency or resource bottlenecks.

Effective scaling involves understanding which component is under pressure and expanding that layer rather than increasing resources indiscriminately.

Because Wazuh separates event processing, storage, and visualization into distinct components, each layer can be scaled independently.

Vertical Scaling

Vertical scaling increases the resources available to an existing server.

Typical upgrades include:

Additional CPU cores
More RAM
Faster storage (SSD or NVMe)
Higher network bandwidth

Vertical scaling is often the simplest solution when resource utilization is approaching capacity but overall architecture remains sufficient.

Advantages include:

Minimal architectural changes
Lower administrative overhead
Faster implementation
No cluster expansion required

However, vertical scaling is ultimately limited by the maximum hardware capacity of a single server.

Horizontal Scaling

Horizontal scaling adds additional nodes instead of increasing the size of existing ones.

Examples include:

Additional worker managers
More Indexer nodes
Extra Dashboard instances
Multiple Filebeat outputs

Benefits include:

Nearly linear scalability
Improved fault tolerance
Better workload distribution
Easier future expansion
Reduced hardware limitations

Modern enterprise SIEM deployments generally favor horizontal scaling because it aligns with distributed systems principles and provides greater operational resilience.

When to Add Worker Nodes

Adding worker managers is appropriate when event processing becomes the primary bottleneck.

Common indicators include:

High CPU utilization on managers
Increasing alert latency
Event processing queues growing
Large numbers of connected agents
Slow rule execution
Delayed active responses

Rather than continually upgrading one manager, distributing workloads across additional workers often provides better long-term scalability.

For more scaling instructions, see our Step-by-Step Wazuh Manager Scaling Guide.

When to Expand the Indexer Cluster

Storage infrastructure should be expanded when indexing performance becomes the limiting factor.

Signs include:

Slow Dashboard searches
Increased indexing latency
Growing storage consumption
Heap memory pressure
Large shard sizes
High disk utilization

Expanding the Indexer cluster by adding nodes and rebalancing shards helps maintain fast search performance while accommodating growing data volumes.

OpenSearch recommends monitoring shard distribution, JVM heap utilization, and storage growth to determine when cluster expansion is necessary.

Capacity Planning

Capacity planning helps organizations scale proactively instead of reacting after performance problems occur.

Factors to evaluate include:

Number of monitored endpoints
Average events per second (EPS)
Log retention requirements
Peak ingestion periods
Rule complexity
Active response usage
Available hardware resources
Expected annual growth

Regularly monitoring key performance metrics, such as CPU utilization, memory usage, indexing throughput, search latency, disk consumption, and agent counts, allows administrators to identify trends before they impact production.

For enterprise environments, it’s also a best practice to perform periodic load testing and review infrastructure growth every few months.

Proactive capacity planning reduces the risk of bottlenecks, improves budget forecasting, and ensures the Wazuh deployment can continue to meet operational and security requirements as the organization expands.

Performance Optimization

A well-designed Wazuh cluster can handle very large workloads, but achieving consistent performance requires ongoing optimization.

As the number of monitored endpoints, security events, and indexed alerts grows, administrators should regularly evaluate each layer of the architecture to eliminate bottlenecks before they affect production.

Performance tuning should focus on the entire data pipeline, from agent communication and event analysis to indexing and dashboard searches, rather than a single component.

Cluster Synchronization Optimization

Cluster synchronization ensures that every manager shares the same configuration, rules, decoders, and agent metadata.

While synchronization traffic is relatively lightweight, inefficient cluster design can still introduce delays.

Best practices include:

Deploy cluster nodes on low-latency, high-bandwidth networks.
Avoid high-latency WAN links whenever possible.
Minimize unnecessary configuration changes during peak ingestion periods.
Monitor synchronization logs for repeated retries or failures.
Ensure all cluster nodes use synchronized system time with NTP.

Time synchronization is particularly important because clock drift can interfere with cluster coordination and troubleshooting.

Database Optimization

The wazuh-db service performs frequent read and write operations during agent communication, File Integrity Monitoring (FIM), inventory collection, and vulnerability detection.

Performance can be improved by:

Using fast SSD or NVMe storage.
Monitoring disk I/O latency.
Maintaining adequate free disk space.
Preventing filesystem fragmentation.
Monitoring database health for corruption.
Avoiding resource contention with unrelated workloads.

Administrators should also investigate abnormal database growth or repeated database errors before they begin affecting event processing.

Related Guides:

Indexer Performance Tuning

In many enterprise environments, the Wazuh Indexer becomes the most resource-intensive component because it continuously indexes, stores, and searches security data.

Optimization techniques include:

Allocate appropriate JVM heap memory.
Use dedicated SSD or NVMe storage.
Configure appropriate shard sizes.
Use replica shards for resilience.
Implement Index Lifecycle Management (ILM).
Delete or archive expired indices.
Monitor garbage collection activity.
Avoid oversized shards that slow searches.

The OpenSearch Project recommends monitoring heap utilization, indexing throughput, query latency, and disk usage as key indicators of cluster health and performance.

Related Guide: How to Build a Wazuh Indexer Cluster

Network Optimization

Firstly, network performance directly affects every stage of the Wazuh architecture, from agent communications to cluster synchronization and alert forwarding.

Network optimization recommendations include:

Deploy managers and Indexers on high-speed networks.
Minimize latency between cluster nodes.
Reserve bandwidth for security telemetry.
Monitor packet loss and retransmissions.
Use dedicated management networks where appropriate.
Optimize firewall rules to reduce unnecessary inspection overhead.
Continuously monitor network latency between cluster components.

Reliable network connectivity is particularly important for large distributed deployments where delays can affect synchronization and indexing performance.

Resource Allocation Best Practices

Each Wazuh component has different resource requirements. Allocating CPU, memory, and storage based on the workload of each service helps maximize overall cluster efficiency.

General recommendations include:

Component	Primary Resource Requirements
Wazuh Manager	CPU, memory
Wazuh Indexer	Memory, storage, CPU
Filebeat	CPU, network bandwidth
Dashboard	CPU, memory
Wazuh DB	Fast storage, memory

Additional best practices include:

Separate production workloads from unrelated services.
Avoid oversubscribing virtual machines.
Monitor CPU steal time in virtualized environments.
Scale horizontally before servers reach sustained resource saturation.
Continuously monitor resource trends to anticipate future growth.

The official Wazuh documentation recommends monitoring cluster resource utilization regularly and scaling components independently as workloads increase.

Security Best Practices

Because a Wazuh cluster processes sensitive security telemetry and administrative data, securing the architecture is just as important as scaling it.

A compromised management infrastructure can expose endpoint information, weaken threat detection, or allow attackers to interfere with monitoring operations.

The following practices help protect clustered Wazuh deployments against unauthorized access and operational risks.

Secure Cluster Communications

Communication between managers, Indexers, Dashboards, and agents should occur only over trusted networks.

Recommended practices include:

Isolate cluster traffic from user networks.
Use private network segments or VPNs for inter-node communication.
Restrict access with firewalls or security groups.
Monitor cluster communication logs.
Disable unnecessary services on cluster hosts.

Limiting network exposure significantly reduces the attack surface of the deployment.

TLS Certificates

TLS encryption protects sensitive data exchanged between Wazuh components.

It should be enabled for:

Agent-to-manager communication
Filebeat-to-Indexer communication
Dashboard-to-Indexer communication
Dashboard-to-API communication
Administrative web interfaces

Certificate management best practices include:

Use certificates issued by a trusted internal or public Certificate Authority (CA).
Rotate certificates before expiration.
Protect private keys with appropriate filesystem permissions.
Remove expired or unused certificates.
Regularly verify certificate validity.

Proper certificate management prevents interception and impersonation attacks.

Restrict Cluster Ports

Every exposed network port represents a potential attack surface.

Administrators should:

Allow only required ports.
Restrict access using firewall rules.
Limit management interfaces to trusted administrative hosts.
Disable unused services.
Periodically review exposed ports.

Network segmentation is especially important in environments that span multiple subnets or cloud regions.

Secure API Access

The Wazuh API provides powerful administrative capabilities and should be protected accordingly.

Recommended practices include:

Enforce strong authentication.
Use HTTPS exclusively.
Rotate API credentials regularly.
Restrict administrative accounts.
Monitor authentication failures.
Disable unused API accounts.

Organizations integrating Wazuh with automation platforms should grant only the permissions required for each integration.

Role-Based Access Control

Role-Based Access Control (RBAC) ensures users have access only to the resources required for their responsibilities.

Typical roles include:

SOC analyst
Security administrator
Compliance auditor
Infrastructure administrator
Read-only users

Applying the principle of least privilege reduces the impact of compromised accounts and minimizes accidental configuration changes.

Related Guide: Troubleshooting Wazuh RBAC

Backup Strategy

Even highly available clusters require a comprehensive backup strategy.

Hardware failures, software defects, accidental deletions, or ransomware attacks can affect synchronized configurations and operational data.

A complete backup strategy should include:

Wazuh Manager configuration
Custom rules and decoders
Agent groups
Authentication keys
Index snapshots
TLS certificates
Dashboard configuration
Disaster recovery documentation

Backups should be:

Automated
Encrypted
Stored offsite
Tested regularly through restoration exercises

The Center for Internet Security (CIS) recommends maintaining secure, tested backups as a foundational security control to support recovery from cyber incidents.

For more detailed backup instructions, see our How to Backup Wazuh Manager Configuration guide.

Monitoring Cluster Health

Continuous monitoring helps administrators identify problems before they affect security operations.

By tracking synchronization status, resource utilization, and service health, organizations can quickly detect performance degradation, failed nodes, or communication issues.

An effective monitoring strategy combines built-in Wazuh tools with operating system metrics and infrastructure monitoring platforms.

Cluster Status Commands

Wazuh provides commands and APIs that allow administrators to verify the health and status of cluster components.

These tools can be used to monitor:

Cluster membership
Connected nodes
Node roles
Synchronization status
Service availability
Agent counts

Regularly checking cluster status helps detect issues before they begin affecting event processing.

The official Wazuh documentation provides the latest cluster management commands and diagnostic procedures.

Monitoring Synchronization

Configuration synchronization should be monitored continuously to ensure all nodes remain consistent.

Administrators should watch for:

Synchronization failures
Delayed updates
File transfer errors
Repeated retries
Version mismatches
Time synchronization issues

Unexpected synchronization failures often indicate underlying network, filesystem, or clock synchronization problems.

Detecting Failed Nodes

Promptly identifying unavailable cluster nodes minimizes downtime and reduces the risk of interrupted monitoring.

Warning signs include:

Missing heartbeat messages
Unreachable managers
Failed synchronization
Agent reconnection events
Dashboard health warnings
Load balancer health check failures

Automated infrastructure monitoring tools can notify administrators immediately when nodes become unavailable.

Monitoring Resource Utilization

Resource monitoring helps identify performance bottlenecks before they affect production.

Key metrics include:

Managers

CPU utilization
Memory consumption
Event processing rate
Queue sizes

Indexer

JVM heap usage
Search latency
Indexing throughput
Disk utilization
Shard allocation

Dashboard

Response times
Concurrent users
API latency

Operating System

Network throughput
Disk I/O
Filesystem capacity
System load

Monitoring these metrics over time supports proactive capacity planning and informed scaling decisions.

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

Log Files to Watch

System logs provide valuable insight into cluster health and often reveal issues before they become visible through dashboards or monitoring tools.

Important logs to review include:

Wazuh Manager logs
Cluster synchronization logs
wazuh-db logs
Filebeat logs
Wazuh Indexer logs
Dashboard logs
Operating system logs

Administrators should regularly review these logs for:

Authentication failures
Synchronization errors
Service restarts
Network connectivity issues
Database warnings
Indexing failures
Resource exhaustion events

Integrating these logs into centralized monitoring and alerting systems enables faster detection of operational issues and supports a more resilient Wazuh deployment.

Common Wazuh Cluster Problems

Even with proper architecture and sizing, Wazuh clusters can experience operational issues caused by configuration changes, network problems, resource limitations, or component failures.

Understanding the most common failure scenarios allows administrators to quickly diagnose problems and restore normal security monitoring operations.

The majority of cluster issues fall into a few categories:

Synchronization failures
Database problems
Node availability issues
Communication failures
Data forwarding problems
Resource bottlenecks

Master-Worker Synchronization Issues

Configuration synchronization is one of the most important functions of a Wazuh cluster.

When master and worker nodes become inconsistent, administrators may experience unexpected behavior such as missing rules, outdated configurations, or different detection results between nodes.

Common causes of synchronization problems include:

Time differences between cluster nodes
Network connectivity issues
Firewall restrictions
Incorrect cluster configuration
File permission problems
Corrupted synchronization data
Version mismatches between nodes

Symptoms may include:

Worker nodes showing outdated configurations
Custom rules not appearing on workers
Agent metadata inconsistencies
Cluster status showing disconnected nodes
Repeated synchronization failures in logs

To prevent synchronization issues:

Use NTP or another reliable time synchronization service.
Ensure all nodes have matching Wazuh versions.
Monitor cluster logs regularly.
Verify network connectivity between cluster members.
Avoid manually editing synchronized files on worker nodes.

Clock synchronization is particularly important because distributed systems rely on accurate timestamps for coordination, logging, and troubleshooting.

Database Corruption

The Wazuh DB stores important operational information used by the Wazuh Manager.

If database files become corrupted, managers may fail to process events correctly or lose access to stored agent information.

Common causes of database corruption include:

Unexpected system shutdowns
Disk failures
Filesystem errors
Storage exhaustion
Interrupted write operations
Hardware failures

Potential symptoms include:

wazuh-db service failures
Missing agent information
Failed inventory queries
FIM data inconsistencies
Database startup errors

Recovery steps typically include:

Stop affected Wazuh services.
Create a backup copy of existing database files.
Validate database integrity.
Restore from a known-good backup when available.
Restart services and verify cluster synchronization.

Because database corruption can affect multiple Wazuh features, regular backups and storage monitoring are essential.

For more database recovery instructions, see our How to Recover From a Malformed Database Image in wazuh-db guide.

Worker Node Offline

Worker nodes handle much of the event processing workload in a clustered deployment.

If a worker becomes unavailable, agents connected to that node may temporarily lose communication or experience delayed event processing.

Common causes include:

Hardware failure
Service crashes
Network interruptions
Resource exhaustion
Incorrect configuration
Failed upgrades

Symptoms include:

Missing heartbeat communication
Agents showing disconnected status
Reduced processing capacity
Increased workload on remaining workers

Recommended troubleshooting steps:

Verify the Wazuh Manager service status.
Check system resource utilization.
Review manager and cluster logs.
Confirm network connectivity with the master.
Validate cluster configuration.
Restart services only after identifying the root cause.

Organizations using multiple workers should configure load balancing and health checks to minimize the impact of individual node failures.

Related Guide: How to Set Up a Multi-Node Wazuh Cluster

Cluster Communication Failures

Wazuh cluster nodes must communicate continuously to exchange synchronization data and maintain cluster state.

Communication failures can result from:

Firewall changes
Incorrect IP addresses
DNS resolution problems
Network segmentation
Certificate issues
Port restrictions

Common symptoms include:

Nodes disappearing from cluster status
Synchronization delays
Failed configuration updates
Worker nodes unable to contact the master

Troubleshooting should include:

Testing network connectivity between nodes.
Verifying required ports are open.
Reviewing cluster logs.
Checking certificates.
Confirming hostname resolution.

Network reliability is especially important in multi-datacenter deployments where latency and packet loss can impact cluster synchronization.

Filebeat Delivery Problems

Filebeat provides the connection between Wazuh Managers and the Wazuh Indexer.

When Filebeat fails, alerts may still be generated by managers but never appear in the Dashboard.

Common Filebeat problems include:

Incorrect Indexer address
TLS certificate errors
Authentication failures
Network connectivity issues
Queue overflow
Incorrect Filebeat configuration

Symptoms include:

Missing alerts in the Dashboard
Filebeat connection errors
Failed indexing attempts
Growing alert files on managers

Troubleshooting steps include:

Checking Filebeat service status.
Testing connectivity to Indexer nodes.
Validating certificates.
Reviewing Filebeat logs.
Confirming output configuration.

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

Database Performance Issues

Database performance problems can affect how quickly Wazuh retrieves and stores operational data.

Common causes include:

Large agent databases
Slow storage
Excessive FIM activity
High inventory collection frequency
Resource contention
Disk performance limitations

Symptoms include:

Slow agent queries
Delayed inventory updates
Increased manager resource usage
Slow Dashboard responses

Optimization strategies include:

Using faster storage.
Monitoring database size.
Reducing unnecessary data collection.
Reviewing module configurations.
Monitoring wazuh-db performance.

Related Guide: Understanding the Wazuh DB Architecture

Integrating External Data Sources

One of the biggest advantages of Wazuh cluster architecture is its ability to collect and analyze security telemetry from many different sources.

A properly designed cluster can ingest data from databases, cloud platforms, network appliances, operating systems, and container environments while maintaining centralized detection and investigation capabilities.

MySQL Monitoring

Database systems contain valuable security information, including authentication attempts, privilege changes, administrative actions, and suspicious queries.

Wazuh can monitor MySQL environments by collecting database audit logs and applying detection rules to identify suspicious behavior.

Common monitoring use cases include:

Failed database logins
Privilege escalation attempts
Unauthorized schema changes
Administrative activity
Sensitive data access

In enterprise environments, MySQL monitoring can be distributed across multiple Wazuh agents while cluster workers process the resulting security events.

Cloud Services

Modern organizations increasingly rely on cloud platforms that generate large volumes of security telemetry.

Wazuh can integrate with cloud services to monitor:

Identity activity
API calls
Configuration changes
Network events
Security findings
Resource modifications

Common cloud integrations include:

AWS CloudTrail
Azure activity logs
Google Cloud logging services

Cloud monitoring benefits from clustered deployments because multiple worker nodes can distribute processing workloads generated by large cloud environments.

Network Devices

Network infrastructure generates critical security information that helps detect attacks and unauthorized activity.

Wazuh can collect logs from:

Firewalls
Routers
Switches
VPN appliances
IDS/IPS platforms
Security gateways

Common detections include:

Port scanning
Authentication failures
Suspicious connections
Policy violations
Malware-related traffic

Centralizing network telemetry with endpoint and cloud data provides a broader security view across the organization.

Related Guide: How to Collect Firewall Logs in Wazuh

Linux and Windows Servers

Operating systems remain one of the most common data sources in SIEM deployments.

Wazuh agents can monitor:

Linux systems:

SSH authentication events
System logs
Privilege escalation attempts
File changes
Process activity

Windows systems:

Security event logs
PowerShell activity
Authentication events
Registry modifications
Malware indicators

A clustered architecture allows organizations to monitor thousands of servers without overwhelming a single manager.

Related Guides:

Containers and Kubernetes

Container environments introduce dynamic infrastructure where workloads frequently start, stop, and move between hosts.

Wazuh can monitor Kubernetes environments by collecting:

Container logs
Kubernetes audit logs
Node activity
Runtime security events
Configuration changes

Clustered Wazuh deployments are especially useful for Kubernetes environments because container platforms often generate high event volumes.

Related Guide: How to Monitor Kubernetes Using Wazuh

Wazuh Cluster Best Practices

Building a reliable Wazuh cluster requires more than adding additional nodes.

Long-term stability depends on consistent configuration management, operational discipline, security controls, and continuous monitoring.

The following practices help maintain a healthy production deployment.

Keep Node Configurations Consistent

All cluster nodes should maintain consistent:

Wazuh versions
Operating system versions
Configuration files
Network settings
Security policies
Certificates

Configuration drift between nodes can lead to inconsistent alert processing and difficult troubleshooting scenarios.

Use centralized configuration management tools whenever possible to maintain consistency across environments.

Synchronize System Time

Accurate time synchronization is critical in distributed security systems.

All nodes should use reliable time synchronization services such as:

NTP
Chrony
Cloud provider time services

Incorrect timestamps can affect:

Cluster synchronization
Incident investigations
Log correlation
Alert timelines

Separate Processing and Storage

Avoid combining all Wazuh components on the same server in large deployments.

A scalable architecture separates:

Manager nodes for event processing
Indexer nodes for storage and search
Dashboard nodes for visualization

Benefits include:

Better resource utilization
Easier scaling
Improved troubleshooting
Reduced resource contention

Monitor Cluster Health Continuously

Continuous monitoring helps detect problems before they impact security visibility.

Monitor:

Node availability
Synchronization status
CPU usage
Memory consumption
Disk utilization
Index health
Agent connectivity

Proactive monitoring is significantly more effective than troubleshooting after failures occur.

Test Failover Regularly

High availability designs should be tested, not assumed.

Regular failover testing should verify:

Worker node failures
Indexer node failures
Dashboard availability
Backup restoration
Agent reconnection behavior

Testing confirms that recovery procedures work before an actual incident occurs.

Keep All Nodes Updated

Running inconsistent versions across a cluster can create compatibility issues.

Best practices include:

Plan upgrades carefully.
Test upgrades in staging environments.
Upgrade components according to Wazuh recommendations.
Maintain backups before major changes.

Document Cluster Changes

Documentation is essential for maintaining complex security infrastructure.

Record:

Architecture diagrams
Node roles
IP addresses
Certificates
Firewall rules
Configuration changes
Upgrade history
Troubleshooting procedures

Well-maintained documentation reduces recovery time and helps teams understand how the environment operates.

Real-World Example

Scenario

A multinational organization operates more than 40,000 endpoints across North America, Europe, and Asia.

The company uses Wazuh to monitor Windows servers, Linux infrastructure, cloud workloads, network devices, and critical business applications.

Initially, the organization deployed Wazuh using a single Wazuh Manager.

While the standalone deployment worked effectively during the early stages, rapid infrastructure growth created several operational challenges.

The security team began experiencing:

Delayed agent registrations
Longer alert processing times
Increased CPU and memory utilization
Slow Dashboard searches
Resource exhaustion during peak activity periods
Difficulty performing maintenance without disrupting monitoring

As the organization continued expanding, the single-node architecture became a limitation.

The security team decided to redesign the deployment using a scalable Wazuh cluster architecture.

The new architecture included:

One dedicated master node for cluster coordination
Multiple worker nodes responsible for event processing
A load balancer distributing agent connections
A dedicated three-node Wazuh Indexer cluster for storage and search
Redundant Dashboard instances for analyst access
Centralized monitoring for infrastructure health
Automated backup processes
TLS-secured communication between components

The master node became responsible for:

Configuration synchronization
Agent metadata management
Cluster coordination
Worker synchronization

Worker nodes distributed the event analysis workload by processing incoming telemetry from thousands of endpoints.

The Indexer cluster provided:

High-performance searching
Alert storage redundancy
Improved query performance
Increased storage capacity

Filebeat instances on each manager securely forwarded generated alerts to the Indexer cluster using encrypted communication.

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

To maintain operational reliability, the security team also implemented:

Regular Wazuh Manager configuration backups
Cluster health monitoring
Resource utilization tracking
Automated alerting for failed nodes
Time synchronization across all servers

Related Guide: How to Backup Wazuh Manager Configuration

Results

After migrating to the clustered architecture, the organization was able to process millions of security events daily while maintaining consistent detection performance across global locations.

The redesigned architecture provided:

Improved event processing capacity
Reduced alert processing delays
Better fault tolerance
Easier maintenance operations
Independent scaling of managers and Indexers
Greater visibility into infrastructure health

This example demonstrates how proper Wazuh cluster architecture allows organizations to grow from small deployments into enterprise-scale security monitoring platforms without sacrificing performance, availability, or operational control.

Frequently Asked Questions (FAQ)

Question:What is a Wazuh cluster?

A Wazuh cluster is a group of Wazuh Manager nodes that work together as a single security monitoring platform.

The cluster distributes event processing workloads across multiple managers while maintaining synchronized configurations, agent information, and operational state.

A typical cluster contains:

One master node
One or more worker nodes
Wazuh Indexer nodes
Dashboard instances
Filebeat services

Clustering improves scalability, availability, and manageability compared to running a single Wazuh Manager.

Question: What is the difference between a master node and a worker node?

The master node manages cluster coordination tasks, including:

Configuration synchronization
Cluster membership
Agent registration management
Shared data synchronization

Worker nodes primarily process security events from agents.

They handle:

Log collection
Decoding
Rule evaluation
Alert generation
Active responses

Worker nodes allow organizations to distribute processing workloads as their environments grow.

Question: How many nodes should a Wazuh cluster have?

The required number of nodes depends on:

Number of monitored endpoints
Events per second (EPS)
Log retention requirements
Availability requirements
Hardware resources

Small environments may use:

One master
One worker

Enterprise deployments often use:

One master
Multiple workers
Three or more Indexer nodes
Multiple Dashboard instances

There is no universal node count because every environment has different monitoring requirements.

Question: Can multiple worker nodes process the same agents?

No. Agents communicate with a specific Wazuh Manager node.

However, worker nodes collectively process workloads across the environment. By distributing agents between workers, organizations can balance processing requirements and increase capacity.

Load balancing and proper agent assignment strategies help prevent individual workers from becoming overloaded.

Question: Does clustering improve Wazuh performance?

Yes, clustering can significantly improve performance by distributing processing workloads across multiple manager nodes.

Benefits include:

Higher event processing capacity
Lower processing delays
Better resource utilization
Ability to monitor more endpoints

However, clustering does not automatically solve every performance issue.

Poorly sized Indexers, insufficient storage, or network bottlenecks can still limit overall performance.

Question: How does Wazuh synchronize configurations?

The master node synchronizes shared configuration data with worker nodes automatically.

Synchronization includes:

Rules
Decoders
Agent groups
Shared configurations
Lists
Cluster metadata

When administrators modify synchronized files on the master, updates are distributed to workers to maintain consistency.

Question: Can a Wazuh cluster span multiple data centers?

Yes, Wazuh clusters can span multiple locations, but administrators must carefully consider:

Network latency
Bandwidth availability
Reliability between sites
Firewall rules
Synchronization performance

For geographically distributed environments, many organizations prefer regional deployments connected through carefully designed architectures rather than extending a single cluster across unreliable WAN connections.

Question: What ports are required for cluster communication?

Required ports depend on the components being connected.

Common communication paths include:

Agent-to-manager communication
Manager cluster synchronization
Dashboard access
API communication
Filebeat-to-Indexer communication
Indexer node communication

Administrators should only allow required ports and restrict access using firewalls or security groups.

Question: How do I monitor cluster health?

Cluster health can be monitored through:

Wazuh cluster status information
Wazuh API
Manager logs
Indexer health metrics
Operating system monitoring tools
Infrastructure monitoring platforms

Important metrics include:

Node availability
Synchronization status
CPU usage
Memory utilization
Disk usage
Index health
Agent connectivity

Question: What happens if the master node fails?

A master node failure can affect cluster coordination because the master manages synchronization and cluster operations.

However:

Existing worker nodes may continue processing events.
Agent communication may continue depending on the deployment.
Administrative synchronization tasks may be affected.

Organizations requiring higher availability should design recovery procedures and maintain tested backup strategies.

Related Guide: How to Backup Wazuh Manager Configuration

Question: How do I scale a Wazuh cluster?

Scaling depends on which component is experiencing limitations.

Manager processing bottlenecks:

Add additional worker nodes.
Increase manager resources.

Storage and search limitations:

Expand the Wazuh Indexer cluster.
Increase storage capacity.
Optimize indexing performance.

For user access issues:

Add additional Dashboard instances.

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

Question: How often should cluster configurations be backed up?

Backup frequency depends on how frequently changes occur.

Organizations should consider:

Daily automated backups for active environments
Backups before major configuration changes
Backups before upgrades
Regular restoration testing

Important backup data includes:

Rules
Decoders
Agent configurations
Authentication keys
Certificates
Cluster settings

Question: Is Filebeat required in a clustered deployment?

Yes, Filebeat is typically used to forward Wazuh alerts from managers to the Wazuh Indexer.

It provides:

Reliable event delivery
Buffering
Secure transport
Retry handling
Load balancing

Without Filebeat, alerts would not be efficiently transported to the Indexer layer.

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

Question: Can I use an external database like MySQL with Wazuh?

Yes, Wazuh can integrate with external databases such as MySQL for monitoring database activity.

However, MySQL is not a replacement for Wazuh’s internal databases or the Wazuh Indexer.

MySQL integrations are commonly used to monitor:

Authentication events
Database activity
Privilege changes
Suspicious queries

Question: What are the most common causes of cluster synchronization failures?

Common causes include:

Incorrect cluster configuration
Network connectivity problems
Firewall restrictions
Clock differences between nodes
Version mismatches
Certificate issues
Resource exhaustion

Troubleshooting should begin by reviewing cluster logs, verifying connectivity, checking system time, and confirming all nodes use compatible configurations.

Conclusion

A well-designed Wazuh cluster architecture provides the scalability, availability, and flexibility required for modern enterprise security monitoring.

Unlike standalone deployments that eventually become limited by hardware resources, clustered Wazuh environments distribute workloads across multiple components:

Master nodes coordinate cluster operations.
Worker nodes process security events.
Wazuh Indexers store and search security data.
Dashboards provide analyst visibility.
Filebeat reliably transports alerts.
Wazuh DB maintains operational metadata.

Building a scalable deployment requires careful planning around:

Cluster topology
Resource allocation
Network design
Storage requirements
Security controls
Backup strategies
Continuous monitoring

Organizations should focus on proactive maintenance rather than waiting for performance problems to appear.

Regular health checks, configuration synchronization, capacity planning, and failover testing help ensure that the security monitoring platform remains reliable as infrastructure grows.

A successful Wazuh deployment is not only about adding more servers, it is about designing an architecture where every component works together efficiently.

For deeper guidance, explore the related resources:

By following these architectural principles and operational best practices, security teams can build Wazuh clusters capable of supporting enterprise-scale monitoring while maintaining performance, resilience, and long-term reliability.

The Complete Wazuh Cluster Architecture Guide

What Is a Wazuh Cluster?

Advantages of Clustering

Core Components of Wazuh Cluster Architecture

Wazuh Manager

Responsibilities

Event Analysis

Rule Processing

Agent Management

Master Node

Primary Responsibilities

Configuration Synchronization

Agent Registration Management

Cluster Coordination

Worker Nodes

Processing Agent Events

Sharing Workload

Communication with the Master

Failover Considerations

Wazuh Indexer

Storage Architecture

Search Capabilities

Cluster Interaction

Scaling Considerations

Wazuh Dashboard

Visualization Layer

API Communication

Cluster Awareness

Filebeat

Shipping Alerts to the Indexer

TLS Communication

High-Availability Considerations

Wazuh DB

Internal Database Architecture

Agent Database Management

Communication with the Manager

How Wazuh Cluster Communication Works

Internal Cluster Protocol

Secure Node Communication

Cluster Ports

Authentication

Configuration Synchronization

What Files Are Synchronized

How Updates Propagate

Synchronization Intervals

Agent Communication Flow

1. Agent Registration

2. Event Forwarding

3. Response Delivery

Alert Processing Pipeline

Event Collection

Decoding

Rule Matching

Alert Generation

Indexing

Wazuh Cluster Topology

Two-Node Architecture

Three-Node Architecture

Large Enterprise Clusters

Multi-Datacenter Deployments

High Availability in Wazuh Clusters

Load Balancing

Redundant Managers

Indexer Redundancy

Dashboard Redundancy

Avoiding Single Points of Failure

Scaling a Wazuh Cluster

Vertical Scaling

Horizontal Scaling

When to Add Worker Nodes

When to Expand the Indexer Cluster

Capacity Planning

Performance Optimization

Cluster Synchronization Optimization

Database Optimization

Indexer Performance Tuning

Network Optimization

Resource Allocation Best Practices

Security Best Practices

Secure Cluster Communications