As organizations expand their infrastructure, the volume of security events generated across endpoints, servers, cloud environments, containers, and network devices grows rapidly.

A Wazuh deployment that performs well with a few hundred agents may begin to struggle when monitoring thousands of endpoints producing millions of daily events.

Without proper planning, increasing workloads can lead to delayed alerts, higher resource consumption, indexing bottlenecks, and slower incident response.

This is where Wazuh Manager scaling becomes essential.

Scaling ensures that your Wazuh deployment can continue processing security events efficiently while maintaining fast detection times and reliable performance.

Rather than waiting until the manager becomes overloaded, administrators should understand how to expand capacity proactively.

There are two primary approaches to scaling a Wazuh Manager:

Vertical scaling, which increases the CPU, memory, and storage resources available to an existing server.
Horizontal scaling, which distributes workloads across multiple Wazuh Manager nodes operating as a cluster.

Each method has advantages depending on your organization’s size, budget, and availability requirements.

Organizations typically begin considering scaling when they experience:

Rapid endpoint growth
Higher log ingestion rates
Increased detection latency
Performance degradation during peak workloads
Requirements for redundancy and high availability
Compliance-driven monitoring expansion

Fortunately, Wazuh was designed with clustering capabilities that allow deployments to grow from small environments into enterprise-scale security monitoring platforms.

Wazuh Clustering Documentation – https://documentation.wazuh.com/current/user-manual/wazuh-server-cluster/index.html

By the end of this guide, you’ll understand how Wazuh Manager scaling works, recognize when it’s necessary, evaluate different scaling strategies, implement a scalable architecture, and follow best practices for maintaining long-term performance.

You’ll also learn how scaling interacts with Wazuh Indexer, dashboards, agents, and load balancers to build a resilient deployment.

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

Understanding Wazuh Manager Scaling

What Is Wazuh Manager Scaling?

Wazuh Manager scaling is the process of increasing the processing capacity of one or more Wazuh Manager nodes so they can handle larger numbers of connected agents and greater volumes of security events without sacrificing performance or reliability.

Instead of relying on a single server to process every incoming log, Wazuh allows administrators to distribute workloads across multiple manager nodes within a cluster.

Worker nodes share processing responsibilities while the master node coordinates cluster synchronization and centralized management.

Scaling can involve:

Adding CPU cores
Increasing RAM
Improving storage performance
Deploying additional manager nodes
Introducing load balancing
Optimizing rule processing
Separating indexing workloads

The ultimate objective is to maintain low alert latency while ensuring every event is analyzed accurately and efficiently.

How the Wazuh Manager Processes Data

Understanding the internal workflow helps explain why resource requirements increase as deployments grow.

Agent Connections

Every protected endpoint runs a Wazuh Agent that establishes a secure encrypted connection to the manager.

Agents continuously send security telemetry including:

Authentication events
File changes
System inventory
Vulnerability information
Process activity
Log entries

Each additional agent increases:

Active network connections
Memory utilization
Message queue sizes
Authentication overhead

Thousands of simultaneously connected agents require considerably more CPU scheduling and memory management than small deployments.

Related Guide: The Ultimate Wazuh Agent Deployment Guide

Log Collection

The Wazuh Manager receives logs from numerous sources including:

Linux systems
Windows Event Logs
macOS endpoints
Syslog devices
Firewalls
Cloud services
Applications
Kubernetes clusters

Every incoming log must be received, normalized, decoded, queued, and prepared for rule evaluation.

High-volume log sources such as web servers, Active Directory controllers, Kubernetes clusters, and firewalls can generate tens of thousands of events every minute, significantly increasing processing demand.

Rule Processing

After collection, Wazuh evaluates every event against its ruleset.

This stage includes:

Decoder matching
Rule evaluation
Correlation
Threat detection
Alert generation
Severity assignment

Rule evaluation is often one of the most CPU-intensive operations because every event may be compared against hundreds or even thousands of detection rules.

Environments with many custom rules generally require additional processing resources.

File Integrity Monitoring (FIM)

File Integrity Monitoring continuously watches important files and directories for unauthorized changes.

Every detected modification generates additional events that require:

Hash verification
Metadata comparison
Rule evaluation
Alert creation

Large environments monitoring millions of files can significantly increase manager workload, especially during scheduled scans.

Vulnerability Detection

Wazuh periodically collects software inventories from endpoints and compares installed packages against vulnerability databases.

This process includes:

Inventory collection
Version comparison
CVE matching
Alert generation

Organizations monitoring thousands of systems often see substantial CPU and storage requirements during vulnerability assessment cycles.

Active Response

When detection rules are triggered, Wazuh can automatically execute response actions such as:

Blocking IP addresses
Killing malicious processes
Disabling user accounts
Running custom scripts

Although Active Response itself usually has a relatively small performance impact, environments with frequent automated actions still generate additional workload for the manager.

Related Guide: How to Configure Wazuh Active Response

Event Forwarding

Once events have been analyzed, alerts are forwarded to the Wazuh Indexer for storage and visualization through the Wazuh Dashboard.

If the indexing layer cannot keep pace with incoming alerts, queues begin to build, increasing latency across the entire deployment.

This is why Wazuh Manager scaling should always be considered alongside Indexer capacity planning.

Related Guide: How to Build a Wazuh Indexer Cluster

Expert Insight: The Wazuh documentation recommends scaling both the manager cluster and the indexer cluster together for large deployments because ingestion, indexing, and search performance are interdependent rather than isolated components of the architecture.

When Should You Scale a Wazuh Manager?

Scaling should be driven by measurable performance indicators rather than waiting until users begin experiencing problems.

Monitoring CPU utilization, memory consumption, event queues, indexing latency, and alert delays provides early warning that additional capacity is required.

Increasing Number of Agents

One of the clearest signs that scaling is necessary is a rapidly growing number of monitored endpoints.

As new devices are onboarded, the manager must maintain more encrypted sessions while processing larger volumes of telemetry.

Common growth drivers include:

Company expansion
Cloud migrations
Remote workforce adoption
Kubernetes deployments
IoT devices
Additional business locations

Even if individual endpoints generate modest event volumes, thousands of concurrent agent connections create significant cumulative workload.

Higher Event Volume

The number of events processed per second often matters more than the number of agents.

For example:

Domain controllers
Firewalls
Proxy servers
Email gateways
Kubernetes clusters
Web servers

can each produce extremely high log volumes.

As ingestion rates increase, managers require additional CPU resources to keep pace with:

Decoding
Rule matching
Alert generation
Queue management

Organizations should monitor event-per-second (EPS) trends and scale before sustained peaks begin creating processing backlogs.

Performance Bottlenecks

Several warning signs indicate that the current manager is approaching its limits:

High CPU utilization
Memory exhaustion
Growing analysis queues
Delayed alerts
Slow dashboard updates
Agent communication timeouts
Missed active responses

If these issues occur consistently during normal workloads rather than temporary spikes, scaling is typically more effective than continually tuning configuration parameters.

Growing Infrastructure

Modern environments expand beyond traditional physical servers.

Many organizations now monitor:

Virtual machines
Containers
Kubernetes clusters
Cloud workloads
SaaS platforms
Multiple geographic regions

Each new technology introduces additional telemetry sources and often higher event diversity, increasing both processing complexity and infrastructure requirements.

Related Guide: How to Monitor Kubernetes Using Wazuh

High Availability Requirements

Mission-critical security operations cannot depend on a single manager server.

If a standalone manager experiences hardware failure or maintenance downtime, organizations risk losing visibility into security events.

Scaling horizontally with clustered manager nodes provides:

Redundancy
Improved resilience
Easier maintenance
Better workload distribution
Reduced operational risk

The official Wazuh cluster architecture supports high availability by allowing worker nodes to continue processing workloads while the cluster remains synchronized.

Compliance Requirements

Many regulatory frameworks require organizations to collect, retain, and continuously monitor security events across increasingly large infrastructures.

Examples include:

PCI DSS
HIPAA
ISO/IEC 27001
SOC 2
NIST Cybersecurity Framework

As compliance programs mature, organizations often onboard more systems, enable additional monitoring modules, and increase log retention periods.

These changes naturally increase the workload placed on the Wazuh Manager, making scaling an essential part of long-term compliance planning.

Industry Insight: Gartner has consistently emphasized that modern SIEM platforms must be architected for scalability because security data volumes continue to grow due to cloud adoption, endpoint expansion, and increasing detection requirements. Designing for growth from the outset helps avoid costly re-architecture later.

Vertical vs. Horizontal Scaling

Choosing the right scaling strategy is one of the most important decisions when expanding a Wazuh deployment.

While both approaches increase capacity, they solve different problems and come with unique advantages and trade-offs.

In many production environments, organizations begin with vertical scaling because it is simple to implement.

As deployments continue growing, they often transition to horizontal scaling to improve capacity, redundancy, and fault tolerance.

Vertical Scaling (Scale Up)

Vertical scaling means increasing the hardware resources available to an existing Wazuh Manager without changing the overall architecture.

Typical upgrades include:

Adding more CPU cores
Increasing RAM
Migrating to faster NVMe SSD storage
Improving storage controllers
Upgrading network interfaces

For example, a manager running on:

4 CPU cores
8 GB RAM

might be upgraded to:

16 CPU cores
64 GB RAM
Enterprise NVMe storage

The manager continues operating as a single server but gains significantly more processing power.

Benefits

Vertical scaling offers several advantages, particularly for small and medium-sized environments.

Benefits include:

Simple implementation
No cluster configuration required
Lower administrative complexity
No load balancer required
Minimal architectural changes
Lower initial costs
Easier troubleshooting

Because only one server is involved, upgrades can often be completed during scheduled maintenance windows with minimal configuration changes.

Limitations

Despite its simplicity, vertical scaling eventually reaches physical hardware limits.

Common limitations include:

Hardware maximums for CPU and RAM
Single point of failure
Maintenance downtime
Limited redundancy
Scaling eventually becomes expensive
Hardware upgrades often require reboots

Once the server reaches its resource ceiling, adding additional capacity requires moving to a clustered architecture.

Best Use Cases

Vertical scaling works best for organizations that:

Monitor a few hundred to several thousand endpoints
Have moderate event volumes
Operate a single data center
Do not require high availability
Prefer simpler infrastructure management

It is often the first scaling strategy organizations implement before expanding into a cluster.

Horizontal Scaling (Scale Out)

Horizontal scaling increases capacity by adding additional Wazuh Manager nodes rather than increasing the resources of a single server.

Instead of one manager handling every workload, multiple worker nodes process agent traffic while a master node coordinates cluster synchronization and management.

A typical architecture includes:

One master manager
Multiple worker managers
Load balancer
Shared Wazuh Indexer cluster
Wazuh Dashboard

As workloads increase, administrators simply add more worker nodes instead of replacing existing hardware.

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

Benefits

Horizontal scaling provides the greatest long-term flexibility for enterprise deployments.

Major advantages include:

Significantly higher capacity
Improved fault tolerance
High availability
Easier maintenance
Incremental expansion
Better workload distribution
Reduced risk of single-server failures

If one worker node becomes unavailable, other workers continue processing agent traffic, improving overall resilience.

Limitations

Horizontal scaling introduces additional infrastructure complexity.

Challenges include:

Cluster configuration
Load balancer management
Additional servers
Increased operational overhead
Cluster synchronization
More complex monitoring

Administrators must also ensure that manager nodes remain synchronized and that the Indexer cluster can keep pace with increased ingestion rates.

Wazuh Cluster Documentation – https://documentation.wazuh.com/current/user-manual/wazuh-server-cluster/index.html

Best Use Cases

Horizontal scaling is recommended when organizations:

Manage thousands of endpoints
Generate millions of events daily
Require high availability
Operate multiple geographic locations
Run Security Operations Centers (SOCs)
Need continuous uptime during maintenance

Large enterprises almost always benefit from horizontal scaling because capacity can continue expanding as monitoring requirements grow.

Which Scaling Method Should You Choose?

The best scaling strategy depends on your current environment and long-term growth expectations.

Scenario	Recommended Approach
Small deployment (<1,000 agents)	Vertical scaling
Medium deployment with moderate growth	Vertical scaling initially, then horizontal
Large enterprise	Horizontal scaling
High availability required	Horizontal scaling
Limited IT staff	Vertical scaling
Rapid organizational growth	Horizontal scaling

A common migration path is:

Deploy a single Wazuh Manager.
Increase CPU and memory as workloads grow.
Build a clustered manager architecture.
Add worker nodes as event volumes continue increasing.

This phased approach minimizes costs while providing room for future expansion.

Expert Insight: The Wazuh team recommends clustering for environments where availability and scalability are priorities. Rather than relying on increasingly powerful hardware, adding worker nodes distributes processing loads more efficiently and reduces operational risk.

Wazuh Manager Scaling Prerequisites

Before adding hardware or deploying additional manager nodes, it’s important to understand the current health of your environment.

Scaling without first identifying existing bottlenecks can simply move performance problems elsewhere in the architecture.

A thorough assessment helps ensure that new resources are allocated where they will have the greatest impact.

Verify Current Resource Usage

Begin by establishing a performance baseline for your existing Wazuh Manager.

Monitor metrics such as:

CPU utilization
Memory consumption
Disk usage
Disk latency
Queue sizes
Network traffic
Alert processing times

Collecting several days or weeks of metrics provides a much more accurate picture than evaluating performance during a single workload spike.

Estimate Future Growth

Scaling should account for future expansion rather than only current requirements.

Consider projected increases in:

Endpoint count
Cloud workloads
Kubernetes clusters
Applications
Log sources
Detection rules
Compliance requirements

Planning for expected growth reduces the need for frequent infrastructure upgrades.

Check Network Capacity

Network infrastructure often becomes an overlooked bottleneck.

Verify that your environment provides sufficient bandwidth between:

Agents and managers
Manager nodes
Managers and Indexers
Dashboard and Indexers
Load balancers and managers

High latency or packet loss can create agent communication delays that resemble manager performance problems.

Review Cluster Requirements

If you’re planning to scale horizontally, ensure your infrastructure supports clustering.

Review:

Static IP assignments
DNS resolution
Firewall rules
Synchronization ports
Load balancer configuration
Time synchronization (NTP)

Improper networking is one of the most common causes of cluster synchronization issues.

Verify Version Compatibility

Every manager within a cluster should run compatible Wazuh versions.

Running mixed versions can lead to:

Synchronization failures
API incompatibilities
Agent registration issues
Unexpected cluster behavior

Before expanding your deployment, ensure all components, including the Manager, Indexer, Dashboard, and agents, are updated according to Wazuh’s supported compatibility matrix.

Back Up Your Configuration

Always create backups before making infrastructure changes.

Important files include:

ossec.conf
Local rules
Custom decoders
SSL certificates
Authentication keys
Cluster configuration
API configuration

Document your existing architecture so you can quickly restore services if necessary.

Step 1: Measure Current Performance

The first step in any scaling project is determining whether the Wazuh Manager is actually resource constrained.

Performance metrics reveal where bottlenecks exist and help determine whether vertical scaling, horizontal scaling, or configuration optimization is the appropriate solution.

Record baseline metrics before making any changes so improvements can be measured afterward.

CPU Utilization

Rule evaluation, log decoding, vulnerability detection, and FIM all consume processor resources.

Monitor:

Average CPU utilization
Peak CPU usage
CPU load averages
Per-core utilization
Process-level CPU usage

Consistently high CPU usage (for example, sustained utilization above 80–90% during normal workloads) often indicates that the manager is nearing its processing capacity.

On Linux, useful commands include:

top
htop
mpstat
sar -u

Memory Usage

Insufficient memory can lead to swapping, slower processing, and increased alert latency.

Monitor:

Used memory
Available memory
Swap usage
Cache utilization
Memory growth over time

Helpful commands include:

free -h
vmstat
cat /proc/meminfo

A manager that frequently uses swap under normal conditions typically benefits from additional RAM.

Disk I/O

Storage performance directly affects:

Event queues
Log writes
Database operations
Indexing performance

Monitor:

Disk throughput
IOPS
Read latency
Write latency
Queue depth

Useful tools include:

iostat
iotop
sar -d

Fast SSD or NVMe storage can dramatically improve sustained ingestion performance compared to traditional hard drives.

Network Throughput

Managers handling thousands of agents generate significant network traffic.

Measure:

Incoming bandwidth
Outgoing bandwidth
Packet loss
Interface errors
Connection counts
Latency

Useful utilities include:

iftop
nload
ss
netstat

Unexpected bandwidth saturation may indicate the need for additional network capacity or load balancing.

Agent Queue Length

The Wazuh Manager temporarily stores incoming events in processing queues.

Growing queue sizes typically indicate that events are arriving faster than they can be analyzed.

Watch for:

Queue growth over time
Persistent backlogs
Delayed processing
Dropped events

Large or continuously increasing queues are often among the earliest indicators that scaling is required.

Event Processing Rate

Finally, measure how efficiently the manager processes incoming security events.

Track metrics such as:

Events per second (EPS)
Alerts per second
Queue processing times
Alert generation latency
Peak versus average workloads

Comparing normal operating conditions with peak traffic periods helps determine whether the current deployment has sufficient headroom or if additional manager capacity is needed.

Collecting these baseline metrics before scaling also provides a clear benchmark for validating the effectiveness of your upgrades after implementation.

Step 2: Optimize Before Scaling

Before investing in additional hardware or deploying new manager nodes, optimize your existing Wazuh environment.

Many performance issues stem from inefficient configurations rather than insufficient resources.

By eliminating unnecessary workloads, you may significantly increase the number of agents your current infrastructure can support.

Optimization should always be the first step because it reduces operational costs while making future scaling efforts more effective.

Tune Agent Configuration

Every Wazuh Agent contributes to the overall workload of the manager.

Default configurations often collect more data than an organization actually needs.

Review each agent’s configuration and disable modules that are not actively used.

Examples include:

Unused log sources
Disabled FIM directories
Unnecessary command monitoring
Redundant inventory collection
Disabled cloud modules where applicable

Reducing unnecessary telemetry lowers CPU utilization, network traffic, and event processing requirements.

Reduce Unnecessary Log Collection

Collecting every available log may seem beneficial, but excessive logging creates unnecessary processing overhead.

Evaluate whether all monitored logs provide meaningful security value.

Common opportunities include:

Removing duplicate log sources
Excluding verbose debug logs
Filtering application noise
Ignoring temporary files
Monitoring only security-relevant events

Higher-quality logs generally improve detection accuracy while reducing infrastructure costs.

Optimize Custom Rules

Custom detection rules should be reviewed regularly.

Poorly written rules may:

Trigger excessively
Perform unnecessary comparisons
Match overly broad conditions
Generate duplicate alerts

Optimize rules by:

Using specific decoders
Limiting expensive regular expressions
Reducing unnecessary rule chaining
Eliminating duplicate logic
Testing before deployment

Even minor improvements to frequently executed rules can significantly reduce CPU utilization in high-volume environments.

Adjust File Integrity Monitoring

File Integrity Monitoring (FIM) can become resource intensive if configured too broadly.

Consider:

Monitoring only critical directories
Excluding cache folders
Ignoring temporary files
Increasing scan intervals where appropriate
Using real-time monitoring selectively

Large software repositories, container directories, and build environments often generate constant file changes that provide little security value.

Archive Old Alerts

Large alert indexes consume storage, memory, and search resources.

Implement retention policies that:

Archive historical alerts
Delete expired indexes
Compress long-term storage
Separate compliance archives from active data

A well-designed retention strategy improves search performance while lowering infrastructure costs.

Related Guide: How to Configure Wazuh Log Retention

Optimize Indexing

Many apparent manager performance issues actually originate within the indexing layer.

Review your Wazuh Indexer configuration by examining:

Index shard counts
Replica settings
Heap allocation
Disk utilization
Index lifecycle policies
Search performance

Improving indexing efficiency reduces backpressure on the Wazuh Manager and minimizes event processing delays.

Related Guide: How to Build a Wazuh Indexer Cluster

Expert Insight: The Wazuh documentation recommends evaluating the entire data pipeline, including the manager, indexer, and dashboard, before concluding that the manager itself requires additional capacity.

Step 3: Vertical Scaling

If performance bottlenecks remain after optimization, vertical scaling is typically the simplest way to increase processing capacity.

Because the architecture remains unchanged, implementation is generally faster than deploying a clustered environment.

Increase CPU Resources

Most Wazuh Manager workloads are CPU intensive.

Additional processor cores improve:

Rule evaluation
Log decoding
Event correlation
Vulnerability analysis
Queue processing

When upgrading virtual machines, allocate additional vCPUs while ensuring the underlying hypervisor has sufficient physical resources.

Monitor CPU utilization after the upgrade to verify that processing bottlenecks have been reduced.

Add More Memory

Memory shortages frequently lead to swapping, increasing response times throughout the system.

Increasing RAM allows the manager to:

Handle larger queues
Cache more data
Reduce disk access
Improve concurrent processing

Memory upgrades are especially beneficial when monitoring thousands of endpoints.

Upgrade Storage

The storage subsystem directly affects logging performance.

Replace traditional spinning disks with enterprise SSD or NVMe storage whenever possible.

Benefits include:

Faster writes
Lower latency
Higher IOPS
Reduced queue delays
Improved recovery times

Storage improvements often produce noticeable gains during periods of sustained event ingestion.

Optimize Storage Performance

Beyond faster hardware, storage configuration also matters.

Recommended practices include:

Separate operating system and data volumes
Use RAID for redundancy where appropriate
Monitor disk latency
Enable TRIM on SSDs
Maintain sufficient free disk space
Regularly monitor filesystem health

These optimizations help maintain consistent performance under heavy workloads.

Validate Performance Improvements

After completing hardware upgrades, compare new metrics against the baseline collected earlier.

Verify improvements in:

CPU utilization
Memory usage
Event processing rate
Queue length
Alert latency
System responsiveness

If bottlenecks persist despite significant hardware upgrades, the deployment may have reached the practical limits of vertical scaling, making horizontal scaling the next logical step.

Step 4: Horizontal Scaling Using a Wazuh Cluster

Horizontal scaling distributes workloads across multiple manager nodes instead of relying on a single server.

This architecture improves scalability, fault tolerance, and operational flexibility while supporting significantly larger deployments.

A clustered deployment typically consists of one master node and multiple worker nodes behind a load balancer.

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

Understanding Cluster Architecture

A Wazuh cluster is designed to operate as a coordinated group of manager nodes.

The architecture generally includes:

One master node
One or more worker nodes
Load balancer
Wazuh Indexer cluster
Wazuh Dashboard

Worker nodes process agent traffic while the master coordinates synchronization across the cluster.

Master Node Responsibilities

The master node serves as the cluster coordinator.

Its responsibilities include:

Cluster management
Configuration synchronization
Agent registration coordination
Rule distribution
Decoder synchronization
Key management
Cluster health monitoring

Although the master participates in processing, its primary purpose is maintaining cluster consistency.

Worker Node Responsibilities

Worker nodes handle most operational workloads.

Typical responsibilities include:

Receiving agent connections
Processing security events
Rule evaluation
Alert generation
FIM processing
Vulnerability detection

Adding additional worker nodes increases processing capacity almost linearly for many workloads.

Communication Between Nodes

Cluster members communicate continuously to exchange operational information.

Synchronization includes:

Configuration files
Rules
Decoders
Agent information
Authentication data
Cluster state

Reliable, low-latency networking between nodes is essential for maintaining cluster stability.

Synchronization Process

The master node periodically synchronizes shared data with worker nodes to ensure consistent operation across the cluster.

Synchronization includes:

Rulesets
Agent groups
Configuration changes
Shared files
Cluster metadata

Administrators should regularly monitor synchronization status to identify failed transfers or communication issues before they affect production workloads.

Step 5: Configure Additional Worker Nodes

Once the cluster architecture is planned, additional worker nodes can be deployed to expand processing capacity.

Each worker should be configured consistently to ensure predictable performance.

Install Wazuh Manager

Begin by installing the same Wazuh Manager version used throughout the existing cluster.

Follow identical installation procedures and ensure:

Matching software versions
Updated packages
Proper firewall configuration
Network connectivity
Time synchronization

Maintaining consistent software versions reduces compatibility issues during synchronization.

Configure Cluster Settings

Update the cluster configuration on each worker node.

Important settings include:

Cluster name
Node name
Node type
Master node address
Cluster key
Network ports

Ensure every node uses the same cluster configuration except for its unique node identifier.

Register Worker Nodes

After configuration, start the Wazuh Manager service on the worker.

The node should automatically establish communication with the master and join the cluster.

Verify that:

Authentication succeeds
Cluster membership is established
Worker status is reported correctly

Synchronize Configuration

Once connected, allow the worker node to synchronize shared cluster data.

Verify synchronization of:

Rules
Decoders
Shared configuration
Agent groups
Security keys

Any synchronization failures should be resolved before directing production agent traffic to the new worker.

Validate Cluster Health

After deployment, verify that the cluster is operating correctly.

Confirm:

All nodes are online
Synchronization is successful
Agent traffic is balanced
Alerts are generated normally
No queue backlogs exist

Continuous health monitoring helps detect node failures before they affect security monitoring.

Step 6: Configure Load Balancing

A load balancer distributes incoming agent connections across available worker nodes, preventing any single manager from becoming overloaded.

Without load balancing, adding worker nodes provides limited benefits because traffic may still concentrate on a single server.

Why Load Balancing Is Important

Load balancing provides:

Better resource utilization
Higher availability
Automatic failover
Improved scalability
Simplified maintenance

Administrators can remove worker nodes for maintenance while continuing to process events through the remaining cluster members.

Supported Load Balancers

Wazuh can operate behind many standard load balancing solutions.

Common choices include:

HAProxy
NGINX
F5 BIG-IP
AWS Application Load Balancer
Azure Load Balancer
Google Cloud Load Balancer

Choose a solution that supports health monitoring and persistent TCP connections.

Agent Traffic Distribution

The load balancer should distribute new agent connections evenly across worker nodes.

Common algorithms include:

Round robin
Least connections
Weighted balancing
Dynamic balancing

The appropriate algorithm depends on your workload characteristics and infrastructure design.

Session Persistence

Because agents maintain long-lived TCP sessions, session persistence is often recommended.

Sticky sessions reduce unnecessary reconnections and provide more predictable communication patterns between agents and managers.

Health Checks

Configure automated health checks that verify:

Manager availability
Network connectivity
Service responsiveness
Cluster membership

If a worker becomes unavailable, the load balancer should automatically redirect traffic to healthy nodes.

High Availability Design

A highly available architecture should eliminate single points of failure.

Consider redundant:

Load balancers
Manager nodes
Indexers
Storage
Network paths

Designing redundancy into every layer ensures that security monitoring continues during hardware failures or planned maintenance.

Step 7: Scale Supporting Components

Scaling the Wazuh Manager alone is rarely sufficient.

Supporting infrastructure must also grow to handle increased event ingestion, storage, and visualization demands.

A bottleneck in any downstream component can reduce the overall effectiveness of your deployment.

Scaling the Wazuh Indexer

As manager capacity increases, the Indexer must ingest and store a larger volume of alerts.

Scale the Indexer by:

Adding additional nodes
Increasing CPU and memory
Optimizing shard allocation
Expanding storage capacity
Monitoring cluster health

Related Guide: How to Build a Wazuh Indexer Cluster

Scaling OpenSearch

Because Wazuh Indexer is built on OpenSearch, the underlying search infrastructure also requires tuning.

Review:

JVM heap size
Shard distribution
Replica configuration
Index lifecycle policies
Query performance
Cluster balancing

Proper OpenSearch tuning helps maintain fast indexing and responsive searches as data volumes grow.

OpenSearch Performance Documentation – https://opensearch.org/docs/latest/

Scaling the Dashboard

A growing number of users, dashboards, and searches increases demand on the Wazuh Dashboard.

Monitor:

Response times
API latency
Concurrent users
Query execution
System resources

If necessary, deploy additional dashboard instances behind a load balancer to improve availability and responsiveness.

Scaling Storage

Storage requirements increase steadily as organizations retain more alerts for operational analysis and compliance.

Plan for:

Capacity growth
High-performance storage
Backup storage
Archive storage
Storage redundancy

Implement lifecycle policies to move older data to lower-cost storage while keeping recent alerts readily accessible.

Scaling Backup Infrastructure

Finally, ensure your backup strategy evolves alongside your production environment.

Back up:

Manager configurations
Cluster settings
Certificates and keys
Custom rules and decoders
Index snapshots
Dashboard configurations

Regular backup testing is just as important as backup creation.

Periodically perform restoration drills to confirm that critical Wazuh components can be recovered quickly in the event of hardware failure, corruption, or accidental data loss.

Performance Tuning After Scaling

Successfully scaling your Wazuh Manager is only the beginning.

Once additional resources or worker nodes are in place, you should fine-tune the environment to maximize performance and ensure the new capacity is being used efficiently.

Post-scaling optimization focuses on eliminating bottlenecks, improving resource utilization, and maintaining consistent event processing as workloads continue to grow.

Increase Worker Capacity

In a clustered deployment, each worker node contributes to the overall processing capacity.

If monitoring requirements continue to expand, adding worker nodes is often more effective than continually increasing the resources of existing servers.

When increasing worker capacity:

Deploy workers with similar hardware specifications.
Distribute agent connections evenly across nodes.
Monitor individual worker utilization.
Avoid assigning significantly more agents to one worker than another.
Periodically rebalance workloads as the environment grows.

Adding capacity incrementally allows you to scale with demand while minimizing infrastructure costs.

Tune Internal Queues

Wazuh uses internal queues to temporarily store events before they are processed.

If these queues become saturated, alerts may be delayed or, in extreme cases, events may be dropped.

Regularly review:

Queue depth
Queue growth rate
Processing latency
Event backlog duration

If queues consistently remain full, investigate whether additional worker nodes, CPU resources, or configuration changes are required rather than simply increasing queue sizes indefinitely.

Optimize Rule Processing

Rule evaluation is one of the most CPU-intensive operations performed by the Wazuh Manager.

Improve efficiency by:

Removing obsolete custom rules.
Combining similar detection logic.
Reducing expensive regular expressions.
Eliminating duplicate conditions.
Using more specific decoders before applying rules.
Reviewing frequently triggered rules for unnecessary complexity.

Regular rule maintenance can significantly reduce CPU utilization without sacrificing detection quality.

Configure File Descriptor Limits

Large deployments maintain thousands of simultaneous connections, log files, and open sockets.

Ensure your operating system provides sufficient file descriptors by:

Increasing the nofile soft limit.
Increasing the nofile hard limit.
Reviewing systemd service limits.
Monitoring open file usage.

Insufficient file descriptors may cause unexpected connection failures or prevent the manager from opening additional log files.

Improve Network Performance

Network latency directly impacts communication between:

Agents and managers
Manager nodes
Managers and Indexers
Dashboards and Indexers

Improve network performance by:

Using high-speed network interfaces
Minimizing latency between cluster members
Eliminating packet loss
Ensuring sufficient bandwidth
Reviewing firewall inspection policies
Monitoring TCP retransmissions

Reliable networking becomes increasingly important as deployments expand across multiple locations.

Reduce Disk Latency

Even with sufficient CPU and memory, slow storage can limit overall performance.

To reduce disk latency:

Use enterprise SSD or NVMe storage.
Separate operating system and data volumes.
Monitor read/write latency.
Maintain adequate free disk space.
Optimize filesystem settings where appropriate.
Regularly review storage health metrics.

Low-latency storage helps maintain consistent event ingestion and minimizes queue buildup during peak workloads.

Monitoring a Scaled Wazuh Environment

Scaling is not a one-time project. Continuous monitoring is essential to ensure that the environment remains healthy as workloads evolve.

Establish dashboards, alerts, and performance baselines so potential issues can be identified before they affect production security monitoring.

Monitor CPU Usage

Track CPU utilization across every manager node rather than focusing solely on the cluster as a whole.

Monitor:

Average utilization
Peak utilization
Per-core usage
Load averages
CPU spikes during peak ingestion

Persistent CPU utilization above normal operating thresholds may indicate the need for additional worker nodes or rule optimization.

Monitor Memory Usage

Memory consumption should remain stable under normal workloads.

Monitor:

RAM utilization
Swap usage
Cache utilization
Memory growth trends
Memory pressure

Unexpected increases may indicate memory leaks, excessive event queues, or rapidly growing workloads.

Monitor Cluster Health

The cluster itself should be monitored continuously.

Verify:

Node availability
Cluster membership
Synchronization status
Worker responsiveness
Service availability

Automated alerts should notify administrators immediately if a worker node leaves the cluster unexpectedly.

Monitor Agent Connectivity

A healthy cluster depends on reliable communication with connected agents.

Monitor:

Connected agent count
Authentication failures
Reconnection frequency
Agent latency
Offline agents

Sudden drops in connected agents may indicate networking issues, load balancer problems, or manager failures.

Monitor Event Throughput

Track how many events are processed over time.

Useful metrics include:

Events per second (EPS)
Alerts generated per second
Peak ingestion rates
Average processing latency
Queue growth during traffic spikes

Comparing throughput trends against infrastructure growth helps determine when additional scaling is required.

Monitor Synchronization Delays

Configuration synchronization should complete quickly across all cluster nodes.

Watch for:

Delayed synchronization
Failed updates
Configuration mismatches
Node communication timeouts

Persistent synchronization delays may indicate networking problems, overloaded master nodes, or version incompatibilities.

Monitor Disk Usage

Storage utilization should be monitored continuously across managers and Indexers.

Review:

Available capacity
Disk growth trends
Filesystem utilization
IOPS
Disk latency
Snapshot storage

Running out of storage can interrupt event ingestion and negatively impact the entire monitoring environment.

Common Scaling Challenges

Even well-designed Wazuh deployments can encounter challenges as infrastructure grows.

Understanding these common issues helps administrators troubleshoot problems quickly and maintain a stable, high-performing environment.

Uneven Load Distribution

One of the most common issues in clustered environments is an uneven distribution of agent connections.

Symptoms include:

One worker running near 100% CPU while others remain underutilized.
Uneven memory consumption.
Larger processing queues on specific nodes.
Delayed alerts from overloaded workers.

Review your load balancer configuration to ensure traffic is being distributed evenly and verify that session persistence is configured appropriately.

Worker Synchronization Failures

Worker nodes rely on regular synchronization with the master to maintain consistent configurations.

Synchronization failures may result in:

Missing rules
Outdated decoders
Configuration mismatches
Authentication inconsistencies

Common causes include:

Network interruptions
Incorrect cluster keys
Firewall restrictions
Version mismatches
Clock synchronization issues

Cluster Communication Errors

Reliable communication between cluster members is essential.

Problems may arise due to:

DNS failures
Packet loss
High latency
Blocked synchronization ports
Firewall policies
Routing issues

Regular network monitoring helps identify communication problems before they affect production workloads.

High CPU Usage

High CPU utilization remains one of the most frequent scaling challenges.

Possible causes include:

Excessive event volume
Inefficient custom rules
Overly broad FIM monitoring
Vulnerability scans
Burst traffic
Uneven workload distribution

Addressing the underlying workload is generally more effective than simply allocating additional CPU resources.

Memory Exhaustion

Memory pressure can develop gradually as environments grow.

Typical causes include:

Larger event queues
Increased agent counts
Concurrent vulnerability assessments
Growing alert volumes
Insufficient physical RAM

Administrators should monitor memory trends over time and investigate unexpected increases before swapping begins.

Event Processing Delays

Delayed alerts reduce the effectiveness of a SIEM platform.

Potential causes include:

CPU saturation
Full processing queues
Storage bottlenecks
Network latency
Indexing backpressure
Excessive log ingestion

Measuring end-to-end alert latency helps identify where delays are occurring within the data pipeline.

Indexing Bottlenecks

A Wazuh Manager may process events quickly while the Indexer struggles to store them.

Common symptoms include:

Growing indexing queues
Slow dashboard searches
Delayed alerts appearing in dashboards
Increased disk utilization
High JVM memory usage

Scaling the Indexer cluster alongside the manager helps prevent indexing from becoming the primary bottleneck.

Related Guide: How to Build a Wazuh Indexer Cluster

Agent Connection Failures

As deployments scale, maintaining reliable agent connectivity becomes increasingly important.

Connection failures may result from:

Overloaded managers
Network congestion
Misconfigured load balancers
Expired certificates
Firewall restrictions
Authentication failures

Regularly reviewing connection logs and monitoring agent health ensures that endpoints continue reporting security events without interruption.

Best Practices for Wazuh Manager Scaling

A successful Wazuh scaling strategy requires more than adding servers or increasing hardware resources.

Long-term performance depends on proper planning, consistent configuration management, continuous monitoring, and regular optimization.

Following scaling best practices helps organizations avoid unexpected bottlenecks while ensuring that security monitoring remains reliable as infrastructure expands.

Plan Capacity Before Growth

Scaling should be based on expected future requirements rather than reacting to performance failures.

Before expanding your Wazuh environment, estimate:

Future agent growth
Expected event volume
Additional log sources
Compliance requirements
Retention requirements
Cloud workload expansion

Capacity planning allows administrators to deploy resources before performance issues affect detection and response capabilities.

A proactive approach prevents emergency migrations and reduces operational disruption.

Scale Incrementally

Large infrastructure changes introduce unnecessary complexity and risk.

Instead of making major changes at once:

Measure current performance.
Optimize existing configurations.
Increase resources gradually.
Monitor improvements.
Add additional nodes when required.

Incremental scaling makes it easier to identify which changes improve performance and prevents unnecessary infrastructure spending.

Use Dedicated Hardware

Production Wazuh environments should avoid sharing resources with unrelated workloads whenever possible.

Dedicated infrastructure provides:

Predictable CPU availability
Consistent memory performance
Improved storage reliability
Easier troubleshooting
Better security isolation

For larger deployments, dedicated virtual machines or physical servers for Wazuh components are recommended.

Separate Indexing from Management

The Wazuh Manager and Wazuh Indexer perform different roles and have different resource requirements.

The Manager focuses on:

Event collection
Decoding
Rule evaluation
Alert generation

The Indexer focuses on:

Data storage
Searching
Visualization queries
Historical analysis

Separating these workloads prevents indexing operations from consuming resources needed for security event processing.

Related Guide: How to Build a Wazuh Indexer Cluster

Regularly Monitor Performance

A scaled environment requires continuous visibility.

Monitor:

CPU usage
Memory consumption
Disk performance
Network traffic
Event throughput
Agent connectivity
Cluster synchronization

Performance monitoring helps identify trends before they become outages.

Test Scaling Changes

Infrastructure changes should always be validated before production deployment.

Test:

New worker nodes
Load balancer behavior
Configuration synchronization
Failover scenarios
Agent reconnect behavior
Indexing performance

Testing ensures that scaling improvements do not introduce unexpected reliability problems.

Keep Cluster Nodes Updated

All Wazuh components should remain aligned with supported versions.

Maintain consistency across:

Master nodes
Worker nodes
Indexers
Dashboards
Agents

Version mismatches can cause:

Synchronization failures
API problems
Unexpected cluster behavior
Compatibility issues

Before upgrading production systems, test changes in a staging environment.

Wazuh Release Notes – https://documentation.wazuh.com/current/release-notes/index.html

Maintain Configuration Consistency

Cluster nodes should use consistent configurations to avoid unpredictable behavior.

Maintain consistency for:

Rules
Decoders
Cluster settings
Certificates
Authentication configuration
Agent groups

Centralized configuration management reduces manual errors and simplifies administration.

Document Cluster Architecture

Detailed documentation becomes increasingly important as environments grow.

Maintain records of:

Node roles
Server specifications
Network topology
Load balancer configuration
Firewall requirements
Backup procedures
Recovery processes

Good documentation reduces troubleshooting time and makes future scaling easier.

Real-World Example

Scenario

A security operations team initially deploys a single Wazuh Manager to monitor 2,500 endpoints across the organization.

The deployment includes:

Employee workstations
Production servers
Cloud workloads
Container environments
Network infrastructure

Over the next year, the organization experiences rapid growth and expands to more than 15,000 monitored systems.

As additional infrastructure is onboarded, event volume increases significantly due to:

More operating system logs
Additional cloud telemetry
Increased application monitoring
Expanded compliance requirements

Eventually, the single Wazuh Manager begins showing performance issues, including CPU saturation, delayed alert processing, and slower agent communication.

Challenge

The standalone manager becomes a processing bottleneck.

The security team experiences:

Increased alert latency
Slower dashboard updates
Growing event queues
Reduced responsiveness during peak workloads

At the same time, the organization requires higher availability because security monitoring cannot stop during:

Hardware failures
Maintenance windows
Software upgrades
Infrastructure changes

The existing single-server architecture no longer provides sufficient scalability or resilience.

Solution

The team follows a phased scaling approach.

Phase 1: Optimize Existing Workloads

Before adding infrastructure, administrators reduce unnecessary processing.

They:

Review and optimize custom rules
Remove unnecessary log collection
Adjust File Integrity Monitoring scope
Improve alert retention policies

These changes reduce resource consumption and provide additional capacity.

Related Guide: How to Reduce False Positives in Wazuh

Phase 2: Vertically Scale the Existing Manager

The team increases the resources of the existing manager by adding:

Additional CPU cores
More memory
Faster SSD storage

The upgrade temporarily improves event processing performance and reduces queue growth.

Phase 3: Deploy a Wazuh Cluster

As the organization continues growing, the team moves to horizontal scaling.

The new architecture includes:

Dedicated master node
Multiple worker nodes
Load balancer
Expanded Wazuh Indexer cluster

Worker nodes distribute event processing workloads, while the master maintains cluster coordination.

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

Phase 4: Expand Supporting Infrastructure

The team also scales supporting components by:

Adding Indexer capacity
Increasing storage availability
Improving backup systems
Monitoring cluster performance

Continuous monitoring of CPU, memory, synchronization status, and event throughput ensures that the deployment remains stable.

Result

The scaled Wazuh environment successfully supports thousands of additional agents while maintaining reliable security monitoring.

The organization achieves:

Lower alert latency
Balanced workloads across worker nodes
Improved agent communication
Higher availability
Better operational resilience

The new architecture also provides room for future growth without requiring a complete redesign.

Frequently Asked Questions (FAQ)

Question: What Is Wazuh Manager Scaling?

Wazuh Manager scaling is the process of increasing the capacity of a Wazuh deployment so it can handle more agents, higher event volumes, and larger security workloads.

Scaling can involve:

Increasing hardware resources
Adding worker nodes
Improving storage
Optimizing configurations
Expanding supporting components

Question: How Many Agents Can a Single Wazuh Manager Support?

The number of agents a single Wazuh Manager can support depends on several factors, including:

Server hardware
Event volume
Enabled modules
Custom rules
Log sources
Performance requirements

A lightly configured manager may support thousands of agents, while high-volume environments may require multiple worker nodes.

Organizations should measure events per second rather than relying only on agent count.

Question: What Is the Difference Between Vertical and Horizontal Scaling?

Vertical scaling increases the resources of an existing server.

Examples:

More CPU
More RAM
Faster storage

Horizontal scaling adds additional servers.

Examples:

Additional Wazuh worker nodes
Cluster deployment
Load-balanced architecture

Vertical scaling is simpler, while horizontal scaling provides better long-term scalability and availability.

Question: When Should I Deploy a Wazuh Cluster?

A Wazuh cluster is recommended when organizations require:

Thousands of agents
High event volumes
High availability
Multiple locations
Continuous monitoring during maintenance

Clusters are especially useful for enterprise Security Operations Centers.

Question: Does Scaling Require Downtime?

Not always.

Vertical scaling may require maintenance downtime depending on infrastructure changes.

Horizontal scaling can often be performed with minimal disruption because worker nodes can be added while existing nodes continue processing events.

Question: Can I Add Worker Nodes Later?

Yes.

Many organizations begin with a single Wazuh Manager and transition to a clustered deployment as requirements grow.

Worker nodes can be added later to increase processing capacity and improve availability.

Question: Does the Wazuh Dashboard Also Need Scaling?

Sometimes.

The dashboard typically requires scaling when organizations have:

Many concurrent users
Heavy search activity
Large visualization workloads
Multiple security teams

For most deployments, scaling the manager and indexer provides the largest performance improvements.

Question: How Do I Know When My Manager Needs Scaling?

Common indicators include:

High CPU utilization
Memory exhaustion
Growing event queues
Delayed alerts
Slow dashboard searches
Agent communication problems

Monitoring these metrics helps identify when additional capacity is required.

Question: Can Cloud Deployments Be Scaled the Same Way?

Yes.

Cloud deployments can use the same scaling strategies.

Organizations can scale by:

Increasing virtual machine resources
Adding additional manager nodes
Using cloud load balancers
Expanding storage capacity

Cloud platforms often make vertical and horizontal scaling easier because resources can be adjusted dynamically.

Question: What Is the Best Load Balancer for Wazuh?

The best load balancer depends on your environment.

Common options include:

HAProxy
NGINX
Cloud provider load balancers
Enterprise appliances such as F5

The most important requirements are:

TCP support
Health checks
Session persistence
Reliable failover

Conclusion

Wazuh Manager scaling is essential for organizations that need to maintain reliable security monitoring as infrastructure grows.

A small deployment may operate effectively with a single manager, but increasing endpoint counts, higher event volumes, and stronger availability requirements eventually require a more scalable architecture.

Vertical scaling provides a simple way to increase capacity by adding CPU, memory, and storage resources.

However, horizontal scaling with a Wazuh cluster provides the flexibility, redundancy, and long-term growth potential required by larger environments.

Before scaling, organizations should optimize configurations, reduce unnecessary workloads, and measure current performance.

After expansion, continuous monitoring of resources, cluster health, event throughput, and synchronization ensures that the deployment remains stable.

By planning capacity proactively and implementing the right scaling strategy, organizations can build a Wazuh environment capable of supporting future growth while maintaining fast detection, reliable alerting, and continuous security visibility.

Step-by-Step Wazuh Manager Scaling Guide

Understanding Wazuh Manager Scaling

What Is Wazuh Manager Scaling?

How the Wazuh Manager Processes Data

Agent Connections

Log Collection

Rule Processing

File Integrity Monitoring (FIM)

Vulnerability Detection

Active Response

Event Forwarding

When Should You Scale a Wazuh Manager?

Increasing Number of Agents

Higher Event Volume

Performance Bottlenecks

Growing Infrastructure

High Availability Requirements

Compliance Requirements

Vertical vs. Horizontal Scaling

Vertical Scaling (Scale Up)

Benefits

Limitations

Best Use Cases

Horizontal Scaling (Scale Out)

Benefits

Limitations

Best Use Cases

Which Scaling Method Should You Choose?

Wazuh Manager Scaling Prerequisites

Verify Current Resource Usage

Estimate Future Growth

Check Network Capacity

Review Cluster Requirements

Verify Version Compatibility

Back Up Your Configuration

Step 1: Measure Current Performance

CPU Utilization

Memory Usage

Disk I/O

Network Throughput

Agent Queue Length

Event Processing Rate

Step 2: Optimize Before Scaling

Tune Agent Configuration

Reduce Unnecessary Log Collection

Optimize Custom Rules

Adjust File Integrity Monitoring

Archive Old Alerts

Optimize Indexing

Step 3: Vertical Scaling

Increase CPU Resources

Add More Memory

Upgrade Storage

Optimize Storage Performance

Validate Performance Improvements

Step 4: Horizontal Scaling Using a Wazuh Cluster

Understanding Cluster Architecture

Master Node Responsibilities

Worker Node Responsibilities

Communication Between Nodes

Synchronization Process

Step 5: Configure Additional Worker Nodes

Install Wazuh Manager

Configure Cluster Settings

Register Worker Nodes

Synchronize Configuration

Validate Cluster Health

Step 6: Configure Load Balancing

Why Load Balancing Is Important

Supported Load Balancers

Agent Traffic Distribution

Session Persistence

Health Checks

High Availability Design

Step 7: Scale Supporting Components

Scaling the Wazuh Indexer

Scaling OpenSearch

Scaling the Dashboard

Scaling Storage

Scaling Backup Infrastructure