Where Google SecOps cost ends and self-hosted Wazuh cost begins
Google Security Operations charges a subscription that scales with ingestion and retention, while Wazuh has no license fee. The license of the Wazuh platform is the GNU General Public License version 2, so the cost of a self-hosted Wazuh deployment is infrastructure, storage and staff time. If your renewal or pricing change raises the ingestion tier, the retention period or the cost of exporting data to BigQuery, the question to answer is how much of your current spend is license and how much would move to hardware, storage and people. The Google SecOps figures are not given here. Take them from your own contract, including the ingestion tier, any retention extension and whether BigQuery export depends on an Enterprise Plus entitlement, and confirm with Google how much history remains available if the subscription ends.
Self-hosting costs more in some areas and less in others. The largest recurring items are engineering staffing for the Wazuh indexer, server and dashboard, coverage for alerts outside business hours, and upgrades. Wazuh 4.14 patch releases arrive roughly every one to two months, so someone must schedule and test them. Storage is also a driver you control directly: a retention period you set yourself is paid for in disks or object storage on your own terms. Graylog Open, which is free to self-manage under the Server Side Public License with no ingestion caps, is a useful comparison point if you weigh ingestion-based pricing against a model without per-volume fees. Ask your team to estimate event volume per day and required retention before comparing totals, because the answer changes which costs dominate.
Before you compare totals, ask three questions. What will your team spend on Wazuh operations each month, including on-call rotation and patching? Which hosting model (your own data center, your cloud account or an air-gapped network) fits your data residency rules? And what does a fixed-scope implementation and migration cost in writing? DeployOpen prepares a written scope before work starts and does not publish a price list, so a quote follows from that scope. Use the Wazuh release notes to plan the upgrade calendar as part of the staffing estimate.
Cost components on each side and what recurs
This table compares each cost component of Google Security Operations with its counterpart in a self-hosted Wazuh and OpenSearch stack, and marks whether each cost is one-time or recurring. Read it as a checklist of what to ask for in a Google quote and what your own team will need to budget, since the commercial and self-hosted columns are not priced in the same units.
| Cost component | Google Security Operations | Self-hosted Wazuh and OpenSearch | One-time or recurring |
|---|---|---|---|
| License or package fee | Subscription package priced on ingestion, set by contract | No license fee: Wazuh is GPLv2 and OpenSearch is Apache 2.0, and the OpenSearch FAQ describes no paid edition | Recurring (Google); none (open source) |
| Ingestion overages | Charges above the contracted ingestion volume, as defined in your order form | Not applicable; ingestion is limited by your own indexer sizing and storage | Recurring (Google); none (self-hosted) |
| Retention beyond 12 months | Confirm the retention terms and any additional cost in your contract | Storage you provision and pay for, sized to your own retention policy | Recurring on both sides |
| BigQuery export (Enterprise Plus) | Feature tied to the Enterprise Plus package; confirm pricing and export limits with Google | Not needed for export; data already sits in your own indexer and backups | Recurring (Google); none (self-hosted) |
| Infrastructure and storage | Included in the service fee; you do not size hardware | Servers or cloud instances for the indexer, server and dashboard, plus disk for retained alerts and logs | Recurring |
| Implementation and deployment | Onboarding effort by Google or partners, confirm scope in writing | Design and installation of Wazuh components, indexer cluster and agent rollout, planned against a written scope | One-time |
| Migration from SecOps | Forwarder repointing, rule translation and parallel running, mostly your staff or a partner | Parser and rule translation, data export and history import, plus a parallel run period | One-time |
| SOC engineering time | Rule tuning and content management within the platform | Rule tuning, decoder upkeep, dashboard maintenance and alert triage in your own team | Recurring |
| Support and upgrades | Included in the subscription at the support tier you buy | Wazuh patch releases arrive roughly every one to two months; OpenSearch minor releases about every eight weeks, so plan staff time or a retainer | Recurring |
What moves the comparison most
Google Security Operations pricing and a self-hosted Wazuh stack respond to different inputs. The six factors below decide where the break-even point sits, so check each one against your own environment before you compare totals.
Daily log volume
Google Security Operations packages are priced on ingestion, so every gigabyte you forward adds to the bill. In a self-hosted stack, volume drives indexer storage, CPU and memory instead of a per-unit fee. Measure your current daily ingest by source, including high-volume items such as DNS, proxy and cloud audit logs, and ask the vendor how Unit overages are calculated for your package.
Retention period
Retention is where the two models diverge most. Retention beyond 12 months and BigQuery export are tied to higher-tier options in Google Security Operations, so longer history can change the package you need. Self-hosted retention costs whatever storage you provision for the indexer, so each extra month adds disk and backup capacity. Confirm the retention your regulator or contract requires before sizing either side.
Number of endpoints and agents
Wazuh agents are free to install, so endpoint count mainly affects server capacity, agent management effort and the number of alerts your analysts review. Google Security Operations costs grow with the telemetry those endpoints produce, not with a seat or agent count. Ask how many endpoints generate logs in scope and whether any sources require agentless collection through syslog.
Availability requirements
A single-node Wazuh deployment is cheaper but has no failover. The Wazuh server can run as a cluster for horizontal scaling, and the indexer needs its own redundancy plan. Higher availability adds servers, load balancing and on-call coverage, which recur every month. Google Security Operations availability is provided by the vendor, so the comparison should weigh your internal uptime targets against those hours of engineering work.
Data residency and air-gapped needs
If logs must stay in a specific country or in networks with no internet access, the cloud service may not fit without contract terms you can verify. Wazuh supports an offline installation guide and an offline vulnerability repository, which keeps detection data inside your boundary. Confirm the data location options and any export restrictions with the vendor in writing, and confirm which offline features your version supports.
Skills already on the team
Running Wazuh and OpenSearch requires people who can operate Linux servers, tune indices, write decoders and rules, and upgrade components on a steady schedule. Teams that already run Elastic-style stacks or have SOC engineers comfortable with rule tuning carry less onboarding cost. Teams without that experience should price training or an implementation partner into the self-hosted side, since that cost is one-time but the on-call time recurs.
How to build the comparison with your own numbers
This sequence turns your current Google Security Operations contract and your log estate into a side-by-side model, so the cost comparison rests on your volumes, retention and staffing rather than on generic assumptions. It ends with a total cost view you can take into a renewal or budget discussion.
Pull ingestion volume per log source
Export daily ingestion figures per log source from the SecOps console and your forwarders or Bindplane collectors for the last several months, so you can see both the average and the peak. Record each source with its gigabytes per day and the date range it covers. Ask your Google account team to confirm in writing how ingestion is measured for your package, including whether it is counted before or after parsing. The step is done when you have one table with a daily average and a daily peak for every source.
List retention requirements and storage location
Work with compliance, legal and the data owners to list which log types must be kept, for how long, and in which jurisdiction they must sit. Separate hot search retention from archive retention, because the two cost different amounts on each side. Note any requirement that depends on the BigQuery export option or the Enterprise Plus tier, since those are contract items you must confirm. The step is done when each log source has a retention period, a storage location and a named owner who signed off.
Price the Google side from the written quote
Request the current order form, package terms, overage rates, the data period that applies after the subscription ends and any fees for retention beyond the standard window. Model the bill twice: once at average volume and once at your recorded peak, because overage charges follow the peak, not the mean. Confirm with Google which costs recur annually and which are one-time, such as onboarding or migration services. The step is done when you have a yearly Google figure for both average and peak scenarios, tied to a quote document you can cite.
Size Wazuh indexer and server nodes
Use your daily volume and events-per-second estimate to size the Wazuh indexer, which stores and searches alerts, and the Wazuh server, which runs decoders and rules and can scale as a cluster. Set node counts, CPU, memory and disk for a test environment and a production environment separately, and confirm the sizing against the official Wazuh documentation and a proof-of-concept run on sample traffic. Add a second site or high-availability node only if your uptime requirement needs it. The step is done when you have a node list with specifications and a monthly infrastructure cost from your own cloud or data center rates.
Add storage for the retention window
Multiply your daily indexed volume by the number of retention days for each log type, then add replica copies and a headroom margin for index growth. Repeat the calculation for archive storage if you keep older data in cheaper object storage. Price storage from your own provider's rates, including backup copies and snapshot costs. Compare the result with the Google retention terms from step three, because the difference in retention cost is often one of the largest drivers. The step is done when each log type has a storage figure in terabytes and a monthly cost.
Estimate staff hours for operations and content
Estimate the recurring effort for platform operations, including upgrades, patching, backups, certificate management and capacity reviews. Separately estimate detection content work: writing or converting rules, tuning false positives, maintaining decoders for each log source, and building compliance dashboards. Assign the work to named roles, such as platform engineers and SOC analysts, and convert hours into cost using your own salary or contractor rates. Record which tasks an outside implementation partner would cover under a fixed-scope agreement. The step is done when you have a monthly hour estimate by role and a loaded labor cost.
Add the one-time migration line
List the one-time migration work: repointing forwarders, rebuilding parsers for key log types, translating detection rules, exporting history from Google before the contract ends, and running both platforms in parallel for a validation period. Ask for quotes from internal teams and any external implementation partner, and record the scope each quote covers. Keep this as a separate line so it does not distort the recurring comparison. The step is done when the migration costs sit in their own table with scope, owner and source for each item.
Compare the totals and test the scenarios
Place the Google annual cost and the Wazuh recurring cost side by side, with migration shown as a one-time item in the first year. Run at least three scenarios: average volume, peak volume and a growth case based on your own source roadmap. Record the assumptions behind each number so that a reviewer can change one input and see the effect. Share the model with finance, security and procurement before a decision. The step is done when the model shows annual and multi-year totals for each scenario and every assumption has a named source.
Why retention beyond 12 months and BigQuery export change the math
Retention and export are the two items in a Google Security Operations package most likely to change the cost comparison, so confirm both before you model anything. Ask your Google Cloud account team whether your package includes retention beyond 12 months and whether it includes BigQuery export. BigQuery export is an Enterprise Plus feature, so a lower package may not include it at all. Get the answers in writing, with the retention period, the data types covered and any per-unit charges, because those terms decide how much history you can reach and what it costs to reach it.
Once history lives in your own storage, retention stops being a contract term and becomes a storage sizing decision. You choose how many days of raw and normalized events to keep, which indices hold them and how many replicas the OpenSearch or Wazuh indexer needs. Cost then tracks daily event volume, retention days, compression and replication, and it recurs for as long as the data stays. Size the storage from your measured ingestion over a representative period, not from the package tier, and record the retention period each regulator or contract requires for each log source.
Export limits vary widely, which affects exit planning more than list prices do. Sumo Logic lets users with the Download Search Results capability export up to 100,000 rows per CSV download, so a large history means many searches over shorter time ranges. Splunk offers several paths, including Splunk Web, the CLI, the REST API, SDKs, the dump search command and data forwarding, and it calls the CLI the most stable retrieval method. Ask Google how raw logs, normalized events, rules and parsers can leave the platform, at what volume, and how long extraction takes, because that timing belongs in your migration schedule and cost estimate.
Questions buyers ask about SecOps and Wazuh costs
How much does self-hosting Wazuh cost compared with Google SecOps?
Wazuh has no license fee, so the comparison comes down to infrastructure, storage, staff time and any outside help, set against Google SecOps package fees that scale with ingestion. Google SecOps costs recur on your contract terms and are tied to the volume you send. Wazuh costs recur in the servers, indexer storage, backup and network you pay for, plus the people who run the platform. Ask Google for a written breakdown of package fees, ingestion overages, retention beyond the default period and any BigQuery export charges in Enterprise Plus. Then price your own compute, disk for the retention you need and engineering hours in the same currency. Totals will differ by log volume and retention, so build the model from your own numbers rather than a generic figure.
How long does a migration from Google SecOps to Wazuh take?
The timeline depends on how many log sources you repoint, how many detection rules you translate, and how much history you must keep. Forwarders and Bindplane collectors are usually the first work, followed by Wazuh agent and syslog onboarding, decoder and rule review, and dashboard setup. Translating YARA-L rules to Wazuh rules or Sigma takes time that grows with the rule count. Plan for running both platforms in parallel until detections match the outcomes you expect. Confirm the sequence and duration with a written scope before work starts, because no fixed duration applies to every environment.
Can our team run Wazuh without outside help?
A team with Linux administration, log pipeline and detection engineering skills can operate Wazuh internally, and Wazuh documents several installation paths, including all-in-one installation, Docker, Kubernetes, Ansible and Puppet. The harder part is ongoing operation: tuning decoders and rules, scaling the indexer and server cluster, managing agent upgrades, and keeping up with patch releases. Wazuh 4.14 patch releases arrived roughly every one to two months in 2026, so someone must own the upgrade cadence. Assess your staff against that workload before deciding whether to keep it in house, use a retainer or split the work.
What skills and staff time does a Wazuh deployment need?
The work falls into four groups: platform administration, detection engineering, endpoint and source onboarding, and SOC analyst time for alert triage. Platform administration covers the indexer, server, dashboard and agent fleet. Detection engineering covers rule writing, tuning and mapping compliance dashboards for frameworks such as PCI DSS, GDPR, HIPAA and NIST 800-53. Onboarding covers agents on Linux, Windows, macOS and other supported systems plus agentless devices through syslog. Analyst time depends on alert volume and how well rules are tuned. Estimate each group from your own environment and ask any implementation partner to show the hours behind each line.
How do I size storage for the log retention I need?
Storage is driven by three inputs: daily ingested volume after filtering, the retention period in days, and the indexer replication and overhead you configure. Multiply those inputs, then add headroom for snapshots and backups stored separately. Google SecOps sets retention by contract, so the first step is to confirm what your current package keeps and what you need to keep for audit or investigation. Test index size with a sample of real events before buying disks, because the indexed size of a log source can differ widely from its raw size. Store long-term history on cheaper storage if your retention requirement is mostly for audit.
Does Wazuh need internet access, and what changes for offline installs?
Wazuh does not need internet access to run, but a connected install makes it easier to fetch packages and vulnerability data. The Wazuh offline installation guide covers systems without internet connectivity. For vulnerability detection, an offline vulnerability repository can replace the Wazuh Cyber Threat Intelligence platform, which correlates collected software inventory with vulnerability data. Offline operation shifts cost toward internal mirroring, a process to refresh the repository, and staff time to verify each update. Confirm the update method and frequency for your network before scoping, because it determines how current your vulnerability findings stay.
What should we ask for in a DeployOpen quote for a Wazuh migration?
Ask for a written, fixed scope listing the log sources, detection rules, dashboards, compliance views and systems in the migration. The quote should name the deliverables, the acceptance criteria, the timeline, what the client provides, and which items are one-time versus recurring. DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope with terms agreed before work starts. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope. Ask how cloud, data center or air-gapped requirements change the infrastructure and effort lines.
What migration and SOC engineering time involve
The one-time work in a move from Google Security Operations to Wazuh falls into four streams: repointing log sources, rebuilding detection content, running both platforms in parallel and exporting history before the contract ends. Start by inventorying every log source that feeds SecOps today, including the forwarders and Bindplane collectors that ship them. Each source then needs a Wazuh path, either a Wazuh agent on the endpoint or a syslog or API collection route for devices that cannot run an agent, and each path needs its own decoders and rules checked against real events. Confirm with your SOC which sources are business-critical so they are cut over first.
Detection content is usually the largest variable. Existing YARA-L rules, curated detections and any custom parsers must be translated into Wazuh rules, decoders and, where it helps, Sigma-format content, then tested against replayed or live events. The effort depends mainly on the number of log types you ingest and how many detections your analysts actually rely on, so count both before estimating anything. Run the two platforms in parallel for long enough to compare alert volumes and confirm that high-severity cases still fire, and record every gap you accept. Parallel running also means paying for both platforms for that window, which belongs in the cost model.
Export history before the subscription ends, because retention beyond the contracted period is the point where data can be lost. Ask Google in writing which export options your package supports, including whether raw logs, normalized events, rules and parsers can be retrieved, in what formats, and whether BigQuery export is included in your edition. Enterprise Plus is the edition where BigQuery export is listed as a feature, so confirm your entitlement rather than assume it. Your SOC engineering team and any integrator you engage will need to plan this work as a fixed workstream with its own owner, not as a side task.
How DeployOpen scopes a fixed-price Wazuh implementation
DeployOpen plans and implements self-hosted Wazuh inside your own cloud accounts, data centers or air-gapped networks, so the cost comparison with Google Security Operations becomes a written scope you can review. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Inventory the log sources, endpoints and firewalls that Google SecOps ingests today and mark each one for Wazuh agents or syslog.
- Record the retention periods your regulators and contracts require, and size the Wazuh indexer storage to match them.
- Agree in writing which detection content, compliance dashboards and integrations are in scope, and which are excluded.
How we build
- Deploy the Wazuh indexer, server and dashboard using the installation method your environment permits, including offline installation if required.
- Configure agent enrollment, group policies and remote upgrades so endpoint coverage matches the agreed inventory.
- Set up single sign-on, role-based access and TLS for the dashboard and indexer according to the agreed design.
How we hand over
- Document the architecture, sizing assumptions, retention settings and backup procedures in a handover pack your team can maintain.
- Run agreed test cases against alerts and dashboards, and record the results as evidence for your own review.
- Train your SOC and platform staff on daily operation, rule tuning and upgrade steps before the engagement closes.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the fixed-scope work ends.
- Plan Wazuh patch upgrades on a schedule your change process can approve, based on the release notes for your version line.
- Ask any implementation partner to confirm which compliance evidence DeployOpen prepares and which an independent auditor must issue.
