Splunk cost vs self-hosted Wazuh and OpenSearch: where the money goes
If a Splunk renewal, a licensing change or a data residency requirement is forcing a cost comparison, the first thing to know is that Wazuh (GPLv2) and OpenSearch (Apache 2.0) carry no license fee. The comparison therefore shifts to compute, storage, retention, staff time and outside support. Splunk's charge is tied to how you license the platform, whether by ingest or by workload, so the self-hosted side has to be costed against infrastructure and people instead. Ask your Splunk account team to put the current licensing unit, the contracted volume and any overage terms in writing, so you have a fixed baseline before you model anything else.
Self-hosting tends to cost less where data volume and retention are high and the team already runs infrastructure, because storage and compute scale with what you keep and the license line disappears. It tends to cost more where skills are thin. A Wazuh server cluster and an OpenSearch indexer tier need someone who can size nodes, manage shards, plan index lifecycle policies and run rolling upgrades, and that work recurs with every release. OpenSearch's release schedule and the Wazuh release notes show how often patching happens, so budget for that cadence as an ongoing line, not a one-time project.
Build the model with four recurring lines: indexer and server compute, hot and warm storage for your retention period, engineer hours for detection content and upgrades, and any outside support contract. Price the one-time items separately, including the migration, parallel running and initial rule rebuild. For illustrative purposes only, a team that keeps 90 days of hot data at high volume will see storage dominate, while a team with modest volume and a short retention window will see staff time dominate. Ask any vendor or integrator quoting the work to state which of these lines they include, what they assume about volume and retention, and what support response they commit to in writing.
Which cost components change between Splunk and self-hosted Wazuh and OpenSearch
This table lists each cost component of running security monitoring on Splunk and on self-hosted Wazuh and OpenSearch, who is paid for it, and whether it is one-time or recurring. Read the Splunk column as what you pay a vendor and the self-hosted columns as what you pay for infrastructure, people and optional support. The main takeaway is that open-source licensing removes one line item, while compute, storage, rule work and upgrades stay with you and must be costed explicitly.
| Cost component | Splunk (commercial side) | Self-hosted Wazuh and OpenSearch (no license fee) | One-time or recurring |
|---|---|---|---|
| License or subscription | Recurring fee set by ingest volume or workload, as stated in your Splunk contract. Confirm the metric and any overage terms with Splunk or Cisco. | No license fee for Wazuh (GPLv2) or OpenSearch (Apache 2.0). Paid support, managed hosting or Wazuh Cloud are optional and need a separate quote. | Recurring |
| Compute for indexing and search | Included in Splunk infrastructure you run, or in the cloud service fee if you use Splunk Cloud Platform. Sizing is set by Splunk guidance and your contract. | Indexer, server and dashboard nodes you provision and patch. Indexing and search load drive the node count, and Wazuh server clusters can scale horizontally. | Recurring |
| Storage and retention | Splunk index storage and retention policies in your deployment, or archive options in Splunk Cloud Platform. Confirm archive tiers and export costs with your account team. | Disk, backup and object storage you buy and manage for the Wazuh indexer and OpenSearch indices. Index lifecycle policies decide how long hot and warm data is kept. | Recurring |
| Deployment and implementation | Splunk installation and app setup, often done by your team or a Splunk partner. Ask partners for a fixed-scope quote. | Wazuh offers all-in-one install, OVA, Docker, Kubernetes, Ansible and Puppet paths. OpenSearch offers Docker, Helm, tarball, RPM and Debian packages. Labor is the main one-time cost. | One-time |
| Migration of forwarders and content | Universal forwarder configuration already in place. Little or no new license cost for the existing setup. | Replacing forwarders with Wazuh agents or syslog inputs, plus parallel running until detections match. Effort depends on the number of sources and the volume of SPL content. | One-time |
| Rule and content authoring | Correlation searches and detection content maintained in SPL and your Splunk apps, often with vendor content updates. | Wazuh decoders and rules are maintained by your team, with Wazuh-provided rules as a starting point. Expect ongoing tuning of alerts and new detections. | Recurring |
| Upgrades and patching | Splunk Enterprise minor versions have a published support window. Upgrade effort is planned with Splunk and your change process. | Wazuh 4.14 patch releases and OpenSearch minor releases about every eight weeks must be tested and rolled out by your team. OpenSearch maintenance covers bug and security fixes only. | Recurring |
| Outside support | Included in the Splunk support contract, with the scope set by that contract. | Optional support or retainers from Wazuh, the OpenSearch community or a services firm. Ask each provider what response scope and hours are covered. | Recurring |
| Internal skills | Teams need SPL and Splunk administration skills, which are often already in place. | Teams need Linux, index management, Wazuh rule writing and OpenSearch administration. Training or hiring is a one-time cost plus ongoing staff time. | Recurring |
What moves the Splunk comparison most
Six inputs decide whether a self-hosted Wazuh and OpenSearch stack costs less than Splunk for your environment. Each one shifts cost between licensing, compute, storage, and people, so price each against your own volumes and team before comparing totals.
Daily ingest volume
Daily ingest sets the size of the OpenSearch indexing tier, the number of data nodes, and the disk written per day. Splunk's licensing is commonly tied to ingest or workload, so volume hits your license line directly, while on a self-hosted stack it hits hardware and storage. Ask Splunk for the exact licensing metric in your contract, then measure your real daily volume per source over a representative month before sizing anything.
Retention period and storage tiers
Retention multiplies every other storage cost. Keeping events hot on fast disks is expensive, while older data on cheaper nodes or object storage costs far less. Decide which searches need instant response, which need occasional lookups, and which only exist for audit. Check how Splunk Cloud Platform archives expired data against your own storage, and plan equivalent index lifecycle policies in OpenSearch.
Endpoints and agents
Agent count drives Wazuh server load, agent management effort, and endpoint coverage work. Wazuh agents run on Linux, Windows, macOS, Solaris, AIX and HP-UX, and agentless collection covers devices such as firewalls through syslog. Agent costs are mostly staff time for rollout, group configuration, and upgrades, so count endpoints by platform and note which ones cannot run an agent and will need syslog or API collection instead.
Detection rules and dashboards
Every correlation search you migrate becomes a Wazuh rule, decoder, or OpenSearch dashboard that someone must own. Rule count and dashboard count determine how much tuning, testing, and documentation your team carries after go-live. Inventory the Splunk searches, alerts, and dashboards you actively use, retire the unused ones, and estimate maintenance hours per rule family. Unmaintained content is where self-hosted SIEM programs usually lose time.
Availability and multi-site needs
High availability and multi-site collection add cost in duplicate nodes, replication, network links, and failover testing. Wazuh server can run as a cluster for horizontal scaling, and OpenSearch clusters need planned node roles and replica settings. A single-site lab costs far less to run than a resilient deployment spread across regions or data centers. Define recovery objectives first, then ask for the node count and topology each option needs to meet them.
Team Linux, search, and upgrade skills
Staff time is often the largest recurring cost in a self-hosted stack, and Splunk's administration work does not disappear when you leave it. Your team needs Linux administration, OpenSearch index and security configuration, and a regular upgrade rhythm. OpenSearch releases a new minor version about every eight weeks, and versions receive security patches only during maintenance. Count the skills you already have, then decide whether to train staff or buy outside support.
How Splunk licensing and open-source licensing differ in practice
Splunk is licensed by data ingest or by workload, so the bill tracks the volume you send into the platform and, in many arrangements, the volume you keep searchable. That means cost moves with growth in sources, log verbosity and retention periods, and a renewal can change materially when any of those move. Whether your contract uses ingest, workload or a hybrid model, get the current terms in writing from Splunk or Cisco, since Cisco completed its acquisition of Splunk on March 18, 2024. Ask for the metric definition, how ingest is measured, what counts toward the entitlement, overage rules, and what happens to the entitlement if you move data to a lower-cost tier.
Wazuh is free to use under the GNU General Public License version 2, with an exception that permits linking with the OpenSSL library. OpenSearch is licensed under Apache License 2.0, and the OpenSearch FAQ does not describe any paid edition. Neither license charges per gigabyte, per endpoint or per user. Your legal team should still read both license files against your internal use case, and confirm whether any plugin, dashboard or hosted service you add carries separate terms.
Open-source licenses remove the software fee, not the operating work. Your costs move to compute and storage for the indexer and server, the staff who write and tune decoders and rules, the upgrade and patch cycle, and any outside support contract. Wazuh shipped 4.14 patch releases on six dates in 2026, so plan recurring maintenance time rather than a one-off installation. For a fair comparison, build a cost model with each component on its own line, and ask any partner or vendor for a written quote that separates one-time implementation from recurring run costs.
How to build a Splunk versus Wazuh and OpenSearch cost model
This sequence turns your current Splunk spend and data volumes into a like-for-like cost model, so you can compare the licence line against compute, storage, staff time and outside support for a self-hosted Wazuh and OpenSearch stack over the same period.
Measure daily ingest by data source
Pull the last 12 months of license or workload usage from the Splunk Monitoring Console or your license reports, then break daily ingest down by index and by source type. Your security team owns this step, with the Splunk administrator supplying the reports. It is done when you have an average and a peak daily volume for each major source, such as firewalls, identity providers, endpoints and cloud audit logs, and you can say which sources drive most of the volume.
Inventory sources, endpoints and retention rules
List every forwarder, syslog feed, API integration and endpoint agent that sends data to Splunk, and record the retention period each index requires for hot, warm and cold data. Compliance and legal teams should confirm retention obligations in writing, since these set the storage footprint. Include agentless devices, because Wazuh covers them through syslog collection and periodic API probing, which changes how you count them. It is done when every source has an owner, a volume and a retention requirement.
Size the indexer, server and storage tiers
Translate daily volume and retention into sizing for the Wazuh indexer, the Wazuh server and OpenSearch. Account for replica copies, index overhead and the hot and cold split, and plan for the Wazuh server running as a cluster when horizontal scaling is needed. Ask your platform engineers or implementation partner to confirm node counts and disk types against vendor sizing guidance, since these figures depend on your event size and search patterns. It is done when you have a node and disk plan for each tier, with a documented assumption for every number.
Price compute and storage at your own rates
Apply your own cloud or hardware rates to the sizing plan, separating one-time costs such as hardware purchase, migration tooling and initial configuration from recurring costs such as instances, block storage, object storage, backups and network egress. Cloud finance or infrastructure teams hold the rate cards, so do not use list prices from memory. It is done when each compute and storage line has a monthly and annual figure from your own rates, and the Splunk side uses the same retention periods and volume assumptions.
Estimate staff hours for rules, dashboards and upgrades
Estimate the recurring labor for detection rule maintenance, dashboard upkeep, agent deployment and configuration, and platform upgrades. Include Wazuh release patching, which has come roughly every one to two months across the 4.14 line, and OpenSearch's cadence of a new minor version about every eight weeks, with rolling upgrades that your team schedules and tests. Include the work to rewrite SPL correlation searches as Wazuh rules if you are moving content. Your SOC and platform leads should provide hours from their own tracking. It is done when every labor item has a role, a frequency and an hour estimate with a stated basis.
Add outside support as a separate line
Record outside support as its own line rather than folding it into internal staff time. This covers implementation services, hardening, ongoing retainers, and any vendor support subscription you choose, such as Wazuh Cloud or a commercial support agreement for OpenSearch. Ask each provider for a written quote against the same scope, including what is one-time, what recurs and which upgrades and incidents are covered. It is done when each support option has a written quote or a stated decision not to buy it.
Compare totals over the same period
Place the Splunk renewal, its compute and storage, and staff time on one sheet alongside the Wazuh and OpenSearch totals, using the same number of years, the same volume growth assumption and the same retention periods. Present one-time and recurring costs separately, and show the sensitivity of the result to volume growth and retention changes. Finance and the CISO should review the sheet together. It is done when both options show a total for the same period, every assumption is written beside its figure, and the open questions are assigned to named owners.
Test quotes against the same written scope
Send the same written scope, covering sources, volumes, retention, compliance views and upgrade expectations, to Splunk, to any reseller you use, and to implementation partners such as DeployOpen. Ask each to state assumptions, exclusions and recurring items, and to confirm what their figures include. Compare the returned quotes line by line against your model, and rerun the model wherever the scope differs. It is done when every quote is mapped to a line in your model and each difference has a documented explanation.
What upgrades and support cost after go-live
The recurring cost in a self-hosted Wazuh and OpenSearch stack is staff time spent on upgrades, not license fees. Wazuh 4.14 patch releases arrived on six dates in 2026: 17 March, 23 April, 1 July, 29 July, 23 September and 14 October, roughly one every one to two months. Each release touches the Wazuh indexer, server, dashboard and agents, so the team needs a standing window to test and roll out updates across all four components. Plan that window as a recurring line item, and count the agent rollout across every endpoint group, since agents on Linux, Windows and macOS each need their own validation.
OpenSearch runs on a different clock. The project targets a new minor version about every eight weeks, and each version stays in maintenance until the next major version enters maintenance or one year passes, whichever is longer. During maintenance, versions receive bug fixes and security patches but no new features. That means a cluster can stay on a supported line without feature upgrades, but it still needs regular patching, and a cluster that falls out of maintenance needs a major upgrade. Check the OpenSearch releases page before each renewal to see which versions are in maintenance and when they leave it.
Ask any outside provider exactly what support covers before you sign. Confirm whether the quote includes patch deployment, minor version upgrades, major version migrations, after-hours response, rule maintenance for detections, and agent fleet updates, and whether it is a fixed-scope project or a retainer. Ask who holds the cluster credentials and runbooks after handover. Also confirm what happens to the support commitment if you fall behind on a release, because a stack that skips several patch cycles usually costs more to catch up than to keep current.
Questions buyers ask about Splunk cost and self-hosted effort
Is self-hosting Wazuh and OpenSearch actually cheaper than Splunk?
It can be, but the saving depends on what you currently pay Splunk and what you add back as infrastructure and staff time. Wazuh is licensed under GPLv2 and OpenSearch under Apache 2.0, so neither carries a license fee. Your Splunk bill is driven by ingest or workload licensing, while the self-hosted side costs compute, storage for retention, network, and the people who tune rules and run upgrades. Ask Splunk to confirm your current licensing basis and renewal terms, then model your own daily volume and retention against those components before comparing totals.
How much staff time does it take to run Wazuh and OpenSearch?
The effort is driven by the number of endpoints, the daily event volume, the retention period and how much detection content you write yourself. Wazuh has four components: the indexer, the server, the dashboard and agents. Each needs patching and monitoring, and the server can run as a cluster for horizontal scaling. OpenSearch targets a new minor version about every eight weeks, and during maintenance versions receive bug fixes and security patches but no new features. Plan for recurring work on upgrades, index lifecycle management and rule tuning, and confirm the expected load with Wazuh and OpenSearch documentation against your own environment.
Can our internal team run this without outside help?
A team with Linux, Elasticsearch-family and detection engineering experience can run the stack, but the skills need to exist in-house before go-live. The main gaps are usually sizing the indexer, writing decoders and rules that match your current Splunk correlation searches, hardening the Security plugin's authentication and role-based access, and handling offline updates where networks are isolated. Wazuh documents offline installation and an offline vulnerability repository. Be honest with yourself about on-call coverage, since a single administrator is a common single point of failure.
How long does a migration from Splunk to Wazuh and OpenSearch take?
The timeline depends on the number of data sources, how many correlation searches and dashboards you must rebuild, and how much historical data you need to keep searchable. Running both platforms in parallel until detections match is the usual approach, so the overlap period is a planning decision, not a fixed figure. Ask any implementation partner for a written timeline tied to a defined scope, and confirm with Splunk which export methods fit your historical volume. Splunk documents CLI and REST API export, and that choice affects how long the archive takes to move.
What should we ask for in a quote for a self-hosted SIEM build?
Ask for a fixed scope that lists data sources, endpoints, daily volume, retention periods, and the detection content to be migrated. A useful quote separates one-time work (design, installation, rule migration, integration, hardening, documentation and testing) from recurring work (upgrades, backups, monitoring and rule maintenance). Request the assumed hardware or cloud sizing, who provides the infrastructure, and what is excluded. DeployOpen works from a written scope and does not publish a price list, so the quote follows from that document.
Which Splunk costs stay the same after we switch to open source?
Some costs move rather than disappear. Your data retention still needs disk, backup and possibly archive storage, and Splunk-specific skills in your team may still be needed during parallel running. Any Splunk apps you rely on, such as premium security content, have no direct open-source equivalent in every case, so confirm which ones your environment uses. Review your Splunk contract for notice periods and export rights before deciding timing, and confirm with Splunk how archived data can be retrieved.
What security controls does the self-hosted stack need before it holds sensitive logs?
The OpenSearch Security plugin provides role-based access control, document-level and field-level security, field masking, audit logs and TLS for node and client traffic, and it supports SAML, OpenID Connect, Active Directory, LDAP, Kerberos and JSON Web Token authentication. Wazuh also documents single sign-on. Treat these as features to configure, not defaults to trust: enable TLS, restrict roles, protect the indexer, and test audit logging. Compliance readiness work, including evidence collection, can be scoped separately. DeployOpen prepares controls and evidence, but independent auditors issue any attestation.
How DeployOpen scopes a fixed-price Wazuh and OpenSearch implementation
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Splunk cost vs self-hosted Wazuh and OpenSearch, the work starts with a written scope that sets out which licenses, compute, storage and staff hours the replacement will be compared against before any build begins.
How we scope
- Inventory current Splunk ingest or workload licensing, retention periods and the indexes that drive them.
- Agree in writing which endpoints, log sources, retention targets and Wazuh and OpenSearch components are in scope.
- Confirm current Splunk pricing terms, renewal dates and export rights directly with your Cisco account team before comparing.
How we build
- Size the Wazuh indexer, server and OpenSearch nodes against measured daily volume, retention and replica settings.
- Deploy from your chosen method, such as Ansible, Kubernetes or the offline installation guide, inside your own environment.
- Test detections, dashboards and compliance views against the Splunk outputs they replace before any cutover.
How we hand over
- Document the cost model, sizing decisions, index lifecycle policies and upgrade runbooks for your own staff.
- Deliver configuration as code and record each control so your auditors can trace the evidence to the system.
- Train your operations and security teams on rule authoring, alert triage and routine maintenance tasks.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope work closes.
- Track Wazuh 4.14 patch releases and OpenSearch minor versions against your maintenance window.
- Plan any future renewal or Splunk upgrade decision against the actual running cost of the self-hosted stack.
