Wazuh SIEM Architecture: On-Premise vs Cloud

The Three Core Components

Every Wazuh deployment, however large, is built from three components. The Wazuh manager is the brain. It receives data from agents and syslog, runs the decoder and rule engine, performs file integrity monitoring correlation, vulnerability detection and security configuration assessment, and triggers active response. It also manages agent registration and configuration.

The Wazuh indexer is a fork of OpenSearch. It receives the alerts and events the manager produces, indexes them as searchable JSON, and stores them. It is responsible for search performance, storage and (when clustered) data resilience through replica shards.

The Wazuh dashboard is a fork of OpenSearch Dashboards. It is the web interface analysts use to investigate alerts, explore data, manage rules and view the compliance, FIM, vulnerability and MITRE ATT&CK modules. It queries the indexer and talks to the manager through the Wazuh API.

Data flows in one direction: agents and devices send to the manager, the manager analyses and forwards to the indexer, and the dashboard reads from the indexer and the manager. Understanding that flow is the key to deciding which components to scale and where to add redundancy.

Single-Node Deployment

In a single-node deployment, the manager, indexer and dashboard all run on one host. This is the simplest way to run Wazuh and the standard starting point for evaluations, labs, small offices and SMBs with a modest number of endpoints.

The advantages are obvious: one server to provision, patch and monitor, the lowest cost, and the fastest path to a working SOC. A single reasonably specified server can comfortably support tens to low hundreds of agents depending on log volume.

The limitation is equally clear: there is no resilience. If the host fails, collection, analysis and search all stop, and recent data may be lost. There is also a ceiling on scale, because all three components compete for the same CPU, memory and disk. Single-node is the right answer when simplicity and cost matter more than resilience and scale, and the wrong answer once the environment becomes business-critical.

Distributed Deployment

A distributed deployment separates the components and clusters them. The indexer runs as a multi-node OpenSearch cluster, distributing shards across nodes so that data and query load are shared and replica shards provide resilience. Three indexer nodes is a common starting point for a production cluster because it gives a stable quorum.

The manager can also be clustered, with one node in master mode and one or more in worker mode. The master coordinates configuration and agent registration; the workers share the load of receiving and analysing agent data. Agents connect through a load balancer that distributes them across the workers, so adding workers increases the volume the SOC can ingest.

The dashboard can be deployed redundantly behind a load balancer as well, so the analyst interface stays available if one dashboard node fails. The result is an architecture that scales horizontally: add indexer nodes for storage and search, add manager workers for ingestion, and the deployment grows with the organisation rather than hitting a wall.

On-Premise vs Cloud

On-premise deployment keeps the entire stack on infrastructure you own or colocate. Its strengths are data control and residency (logs never leave your environment, which matters for regulated data and national data-localisation expectations), predictable cost once hardware is bought, and low-latency collection from on-site endpoints. The trade-offs are capital expenditure, the need to size hardware for peak load up front, and your team owning all maintenance and capacity planning.

Cloud deployment runs the same components on cloud compute and storage, or on a managed offering. Its strengths are elastic scale (add nodes on demand), faster provisioning, and shifting hardware ownership to operating expenditure. The trade-offs are ongoing cost that grows with data volume, dependence on bandwidth to ship on-premise logs to the cloud, and the need to confirm that storing security logs with a cloud provider meets your data-residency and contractual obligations.

Many organisations run a hybrid model: a Wazuh manager or collector on-premise close to the endpoints, forwarding to indexer capacity in the cloud, which balances local collection latency against elastic storage. The deciding factors are usually data residency requirements, the volume and location of log sources, and whether the team prefers a capital or operating cost model.

High Availability and Resilience

High availability in Wazuh is built component by component. For the indexer, run a multi-node cluster and configure replica shards so that every index has at least one copy on a different node; the loss of one node then costs no data and no search availability. For the manager, run a master plus multiple workers behind a load balancer, and ensure agents are configured with multiple manager addresses so they fail over automatically if a worker is unreachable.

For the dashboard, deploy more than one instance behind a load balancer so the analyst interface survives a node failure. Underlying all of this, plan for disk and node failure with monitoring, and back up the manager configuration, rules, decoders and key state so the environment can be rebuilt.

Resilience also means not losing data in transit. Agents buffer events when the manager is unreachable and forward them once connectivity returns, which protects against short outages. For longer-term durability, the retention and archiving strategy keeps a durable copy of events beyond the live indexer. Architecture and retention together determine how much the SOC can lose and still recover.

Choosing the Right Architecture

The decision flows from a few questions. How many endpoints and what log volume? Low volume points to single-node; high volume to a distributed cluster. How critical is the SOC? Business-critical monitoring needs the resilience of clustering; a lab or pilot does not. Where must the data live? Residency requirements may force on-premise or a specific cloud region. Capital or operating cost? On-premise favours capital and predictability; cloud favours operating cost and elasticity.

A pragmatic path for many growing businesses is to start single-node for a proof of value, then move to a distributed on-premise or cloud cluster once the SOC proves its worth and volume rises. Designing the collection and retention strategy early means that transition is a scaling exercise rather than a rebuild.

Whatever the shape, the three components and the one-directional data flow stay the same. Architecture is the art of deciding how many of each component to run, where to place them, and how to make them survive failure, all driven by volume, criticality, residency and budget.