Where Microsoft Sentinel cost and self-hosted Wazuh cost differ
Sentinel cost scales with the gigabytes you ingest and keep, plus Azure charges, while Wazuh with OpenSearch carries no license fee but moves the bill to servers, storage, staff time and support. A buyer facing a renewal, a billing change or a data residency requirement should break both sides into components before comparing totals. On the Sentinel side, the recurring items are analytics ingestion, commitment tier pricing if you commit to a volume, retention beyond the default period, and any data lake charges. On the Wazuh side, the recurring items are the virtual machines or hardware for the indexer, server and dashboard, disk for alerts and archives, the people who patch and tune the stack, and whatever support contract you buy. Wazuh is distributed under the GNU General Public License version 2, so the software itself is not a line item, but that does not make it free to run.
The break-even point depends on your own daily volume, how long you retain data, how many analysts you can staff for the platform, and how much of the work you hand to a partner. No price figures are supplied here, so treat any comparison you see elsewhere with caution and build your own model from your ingestion records and retention requirements. Ask Microsoft for a quote that shows analytics ingestion, commitment tier, retention and data lake charges as separate lines at your actual volume. For the self-hosted side, ask your infrastructure team to cost the indexer and storage at the same daily volume and retention period, then add the hours needed for upgrades and rule tuning. Wazuh's release cadence in the 4.14 line means patching is a recurring task, so budget for it.
Plan for the Defender portal change as part of this decision. After March 31, 2027, Sentinel will be available only in the Microsoft Defender portal, and Microsoft states that the move has no extra cost. The cost question changes, though, because Microsoft Defender XDR data privacy and retention policies then apply instead of Sentinel's own settings. Confirm in writing which retention period applies to your workspace after the move, because any retention you need beyond that period becomes a cost you must either pay or export and store yourself.
Cost components on each side, one-time and recurring
This table sets each Microsoft Sentinel charge against the matching self-hosted cost for Wazuh with OpenSearch at the same daily volume. Read the one-time rows as setup spend and the recurring rows as the monthly or annual run cost that scales with data volume and retention. Neither Wazuh nor OpenSearch carries a license fee in the supplied facts, so the comparison turns on infrastructure, staff time and any optional support.
| Cost component | Microsoft Sentinel (commercial side) | Wazuh and OpenSearch (self-hosted side) | One-time or recurring |
|---|---|---|---|
| Analytics ingestion | Billed per GB ingested into the analytics tier, through Azure billing | No ingestion fee. Cost is the compute and disk needed to index the same volume | Recurring |
| Commitment tiers | Optional volume commitments that discount per-GB ingestion, billed whether or not the volume is reached | Not applicable. Capacity is sized once and added as volume grows | Recurring |
| Retention beyond 90 days | Billed per GB retained past the included period, with the rate set in Azure pricing | Disk for the retention window on indexer nodes, plus snapshot storage for older data | Recurring |
| Data lake charges | Separate storage and query charges for long-term data lake tiers | Object or block storage for cold indices or snapshots, sized by the retention policy | Recurring |
| Wazuh and OpenSearch software | Included in the Sentinel service charge | Wazuh is GPLv2 and OpenSearch is Apache 2.0, with no paid edition described in the supplied facts | Not applicable |
| Servers and cluster nodes | None. Microsoft operates the service | Virtual or physical hosts for indexer, server and dashboard roles, scaled as the cluster grows | One-time setup, recurring hosting |
| Implementation | Workspace setup, connector configuration and onboarding effort, mostly internal or partner time | Installation, cluster design, TLS and access setup, sized from the offline or all-in-one guides as needed | One-time |
| Migration of rules and agents | Not needed for the existing platform. Analytics rules may need rework after the Defender portal move | Rewriting KQL analytics rules as Wazuh rules and deploying agents across endpoints | One-time |
| Staff time and support | Administrative effort for connectors, rules and billing review | Ongoing tuning, upgrades, patching and on-call. Optional Wazuh Cloud or vendor support is a separate recurring subscription | Recurring |
How the comparison changes with volume, retention and staffing
A single-region enterprise with steady daily volume usually sees the Sentinel bill follow ingestion and retention closely. Because volume is predictable, the question is less about peak spikes and more about which data sources are billed at the analytics tier, how long data stays in that tier, and whether a commitment tier fits the baseline. On the self-hosted side, the cost lines are compute and storage for the Wazuh indexer and OpenSearch nodes, the time staff spend operating them, and any support contract. Storage and retention tend to grow with every month of history kept, so the architecture decision is mostly a storage decision.
- Analytics ingestion: Confirm which tables are on the analytics tier and which sources could move to a lower-cost tier without losing detections.
- Commitment tiers: Ask whether the steady baseline justifies a commitment and what happens to unused capacity.
- Retention beyond 90 days: Model how long each data type must stay searchable and how much of that history needs to be recalled quickly.
- Self-hosted storage: Estimate disk growth from the same daily volume, including replicas and snapshots.
Ask your Microsoft account team and your partner to put each line item in a written model using your actual volumes.
For a regulated or air-gapped site, the comparison changes because the cloud option may not be available at all. Sentinel runs only in Azure, so the cost question becomes whether a site that cannot send data out can use it, and if not, the realistic cost lines are hardware or private infrastructure, offline software updates, and staff who can operate an isolated stack. Wazuh documents an offline installation guide and an offline vulnerability repository, which shifts cost toward the local operating model. Data residency and audit evidence requirements also add effort that is easy to underestimate.
- Data egress and residency: Confirm in writing whether your data classification allows any cloud processing, since this can decide the platform before cost is compared.
- Offline operations: Plan how threat content, vulnerability data and software packages are refreshed on a schedule you control.
- Infrastructure ownership: Identify who funds and maintains the hardware, power, cooling and spares for the isolated site.
- Evidence and access control: Ask which audit logs, access controls and retention records must be produced for assessors, and who prepares them.
Verify with your compliance function which control expectations apply before you size the environment.
A team with little in-house SIEM staff faces a different balance. Sentinel shifts operating work to Microsoft and the Azure platform, so staff time mostly goes to writing and tuning analytics rules, managing connectors and handling alerts. A self-hosted Wazuh and OpenSearch deployment moves patching, scaling, backup, upgrades and capacity planning in-house, and those tasks recur. For a small team, the hidden cost is often the time needed to keep the platform current, not the licence or the servers. Outsourced operation or a retainer can change this balance, but its fees and scope must be agreed in writing.
- Operating hours: Estimate how many hours per month the team can spend on platform upkeep without neglecting alert triage.
- Upgrade cadence: Wazuh patch releases and OpenSearch minor releases both arrive on regular schedules that someone must follow.
- Skills gap: Check whether anyone can tune detection content, manage cluster health and respond to a node failure.
- Support model: Compare vendor support, community support and a fixed-scope or retainer arrangement, including who is on call.
Ask any implementation partner what they will operate, what they will hand over, and how knowledge transfer is documented.
What moves the comparison most
Six drivers decide whether a Sentinel bill or a self-hosted Wazuh and OpenSearch footprint costs more over time. Several of them push the same cost in opposite directions, so each card names which side it raises and which side it lowers. Settle these inputs before asking for any quote.
Daily ingestion volume
Sentinel bills analytics ingestion by the gigabyte, so every added source and verbose log level raises the subscription line directly. Self-hosted Wazuh instead costs more in indexer nodes, disk and network as volume grows, and that cost steps up in chunks rather than per gigabyte. Measure the real daily volume per source for a typical month, including peaks, before comparing. Ask whether Sentinel filtering or ingestion-time transformations are already in place, since they change the billable figure.
Retention period and queryable history
Sentinel charges separately for retention beyond the included period, and that charge keeps accruing for every day of history you keep. On the Wazuh side, longer retention means more indexer storage and a larger cluster to keep searches responsive. Decide whether auditors need months of history available for live queries or only archived copies they can restore on request. Those two requirements lead to very different storage designs.
Number of endpoints and agents
Sentinel cost is driven mostly by logs flowing in, so an endpoint that sends little data adds little to the bill. Wazuh agents add a small footprint on each host and raise the manager and indexer load as the agent count grows, and each agent also brings vulnerability and inventory data. Count the endpoints you will monitor, the servers, and the devices you will collect through syslog, since they affect sizing on different axes.
Availability and cluster size
Sentinel's availability is part of the Azure service, so you pay for it through the bill and never size it yourself. A self-hosted Wazuh deployment needs redundant indexer nodes, a server cluster for horizontal scaling and backups stored elsewhere, which multiplies compute and storage. Decide the recovery objectives the SOC needs before sizing, because a single-node all-in-one deployment is cheaper but leaves no failover. Ask your team to document the topology they will run.
Detection content to rewrite
Sentinel analytics rules, workbooks and playbooks are tied to its query language and connectors, so moving them costs engineering time that does not appear on either invoice. Wazuh ships its own decoders and rules, and your custom Sentinel detections must be translated into that format and tested again. Inventory the rules you actually use, retire the ones nobody triggers, and budget the rewrite as a one-time project.
In-house skills and support
Sentinel removes the need to run a search cluster, but your team still tunes detections and manages Azure permissions. Running Wazuh and OpenSearch adds cluster operations, upgrades, certificate handling, patching and on-call duties, which are salary costs that recur every month. Ask whether the team already runs Linux, Elasticsearch-family clusters and agent fleets. If not, price external support as a recurring cost and get the scope in writing.
Build the comparison with your own numbers
This sequence turns the cost components into a like-for-like model built from your own Sentinel billing and your own infrastructure quotes. The result is one comparison window in which both platforms carry the same daily volume, retention and staffing assumptions.
Export twelve months of Sentinel billing by meter
The cloud or finance owner pulls the last 12 months of Azure cost data for the Sentinel workspace and the associated Log Analytics charges, grouped by meter. Separate analytics ingestion, commitment tier charges, data retention beyond the included period, data lake and any export or basic logs charges, so each line can be compared on its own. Confirm with your Azure billing contact which meters apply to your tenant and region. Done when every monthly charge is assigned to a named meter and the total matches the invoices.
Record daily ingested volume by table
The security engineering team extracts daily ingested gigabytes per table from the Sentinel workspace usage data for the same 12 months. Note the top sources, such as firewall, identity, endpoint and cloud activity logs, because they drive both the Sentinel bill and the Wazuh indexer sizing. Flag spikes, seasonal peaks and tables that are duplicated or unused. Done when you have a daily volume series and a short list of the tables that account for most of the ingestion.
Define retention targets for each data class
The compliance lead and security team set how long each data class must stay searchable online and how long it must stay in archive or backup. Write these targets per table, because a regulator's retention rule for authentication logs may differ from the rule for network telemetry. Confirm the requirements with your auditors and legal team, not only with the platform team. Done when a signed retention table exists that both cost models use without modification.
Size Wazuh indexer and server nodes
The platform engineer uses the daily volume and retention targets to size the Wazuh indexer and server nodes, then selects a deployment option from the Wazuh deployment options, such as the step-by-step installation, Docker, Kubernetes or the OVA. Confirm the sizing guidance, node counts and storage recommendations against the current Wazuh documentation for your release line, and ask Wazuh or a partner to review the assumptions. Done when you have a written node list with CPU, memory, disk and network specifications for each role.
Price storage, backup and infrastructure from written quotes
The infrastructure owner requests written quotes from your cloud provider or hardware vendor for compute, block and object storage sized from the previous step, plus backup and snapshot retention, network egress and any load balancer or firewall changes. Ask each vendor to state recurring and one-time costs separately, with the pricing period and any commitment terms. Done when every infrastructure line in the model cites a quote with a date and a validity period.
Estimate hours for build, migration and run
The engineering manager and security lead estimate staff hours in three groups: building the platform, migrating detections and data sources from Sentinel, and running it each month. Include agent rollout, rule rewriting, dashboards, patch windows, upgrade testing and on-call coverage. Use internal rates or the quoted rates from any implementation partner, and label these estimates clearly as assumptions to be validated. Done when each group has a total in hours and a named owner who accepted the estimate.
Add support and upgrade effort
The platform owner adds the cost of any paid support contract, the recurring effort to apply Wazuh 4.14 patch releases and OpenSearch minor versions, and the effort to test upgrades in a non-production environment. Check whether your chosen support model covers the components you run, and ask any vendor to state the support scope and response terms in writing. Done when support and upgrade items sit in the recurring cost section with a stated source for each figure.
Compare both platforms over the same period
The finance and security leads place the Sentinel charges and the self-hosted one-time and recurring costs side by side over the same 12-month window and the same daily volume and retention. Show the staff hours as a separate line so the effect of internal labor is visible, and run a sensitivity check on volume growth. Record the assumptions and the owner of each figure. Done when the comparison, its assumptions and the list of open quotes are reviewed and approved by the decision makers.
What the self-hosted stack includes and what you must run
The self-hosted side of this comparison is not one product but four Wazuh components plus a search backend. The Wazuh indexer is the full-text search and analytics engine that stores alerts, the Wazuh server decodes and analyzes agent data with its rules, the Wazuh dashboard is the web interface, and the Wazuh agents run on the endpoints you want to monitor. Each one needs a sizing decision, a host or container, certificates and an owner. The server can run as a cluster for horizontal scaling and manages agent configuration and upgrades remotely, which makes the cluster design a decision you should make early, based on the daily volume you are modeling. Agentless sources such as firewalls can feed the server through syslog collection and periodic API probing, so confirm which of your sources need agents and which do not.
OpenSearch is the indexing and search layer that many self-built stacks put beside or under the Wazuh components, so you should check how your chosen deployment uses it. OpenSearch is licensed under Apache License 2.0, and the OpenSearch FAQ does not describe any paid edition, so the license line in your cost model is zero for the software itself. The OpenSearch Software Foundation is a Linux Foundation project whose board includes members such as AWS, IBM, SAP and Uber, but the Foundation does not oversee the technical direction of the project, so ask any vendor you hire to explain who provides fixes and support for the code you run. Release cadence is the main recurring workload: Wazuh shipped 4.14 patch releases on six dates in 2026, roughly one every one to two months, and OpenSearch targets a new minor version about every eight weeks. Version maintenance ends on a fixed rule, so plan upgrades, test them in a non-production cluster and budget staff time for them every year.
Questions buyers ask before comparing Sentinel and Wazuh costs
Is Wazuh free to run in our own environment?
The Wazuh software is free to download and run. Wazuh is distributed under the GNU General Public License version 2, with an exception that permits linking with the OpenSSL library, so the license cost is zero. The money goes elsewhere: servers or virtual machines for the Wazuh indexer, server and dashboard, storage sized for your retention period, staff time to operate and upgrade the platform, and any outside help you buy. Wazuh Cloud is a separate, paid offering, so confirm with Wazuh which option your team is pricing. Ask Wazuh directly whether any commercial features or support terms apply to your deployment.
What does running Wazuh need from our own team?
Running Wazuh needs people who can operate four components: the Wazuh indexer, the Wazuh server, the Wazuh dashboard and the agents on endpoints. Day-to-day work includes watching cluster health, managing agent configuration and rule updates, applying patch releases and handling storage growth. Wazuh shipped 4.14 patch releases on 17 March, 23 April, 1 July, 29 July, 23 September and 14 October 2026, so plan for regular maintenance windows. Someone also needs to own alert triage, tuning of decoders and rules, and integrations with ticketing or identity systems. Estimate that workload from your own alert volume and staffing model, and confirm it with a pilot in your environment.
How long does a Sentinel to Wazuh migration take?
The duration depends on the scope you agree, not on a fixed template. The main drivers are the number of data connectors to replace with Wazuh agents or syslog collection, how many KQL analytics rules must be rewritten as Wazuh rules, whether historical data must be exported, how many Logic Apps playbooks exist, and how many compliance views your auditors need. Environment factors matter too, including air-gapped or change-controlled networks and how many endpoints need agents. Ask for a written timeline in any quote, broken into discovery, build, parallel run and cutover, and confirm the schedule against your change calendar.
Can our team migrate from Sentinel without outside help?
Some teams can, particularly where they already run Linux, Elastic or OpenSearch and have security engineers who know detection content. The hard parts are usually rewriting detection logic, rebuilding the Microsoft data sources, preserving evidence and retention for audits, and tuning alerts so the new platform does not flood analysts. Outside help can cover one piece, such as a pilot, a rule rewrite or the hardening and documentation, without taking over the whole program. Weigh the internal hours you would redirect from current security work against the cost of a fixed-scope engagement, and confirm the skills gap with a short assessment first.
What does Microsoft say the Defender portal move costs?
Microsoft states that moving Microsoft Sentinel to the Microsoft Defender portal has no extra cost. Microsoft also states that after March 31, 2027, Sentinel will no longer be supported in the Azure portal and will be available only in the Defender portal. The cost question is therefore less about the move itself and more about what changes: when Sentinel runs in the Defender portal, Defender XDR data privacy and retention policies apply instead of Sentinel's, and the Fusion analytics rule is replaced by Defender XDR correlation. Confirm the current billing terms and any retention changes with Microsoft before you build a comparison, because Microsoft's documentation is the authority for those details.
What should a fixed-scope quote for a Wazuh migration include?
A fixed-scope quote should list each deliverable in writing before work starts. Ask for the in-scope log sources and endpoints, the target Wazuh and OpenSearch architecture with sizing assumptions for your daily volume and retention, the list of analytics rules to rewrite and the playbooks to rebuild, the cutover and rollback plan, hardening and backup steps, and the documentation and evidence you will receive. Also ask what is excluded, such as hardware, Microsoft licensing, staff training or post-go-live support, and whether ongoing support is offered as a separate retainer. Ask DeployOpen for a written scope so that deliverables, timelines and responsibilities are clear before anything begins.
Which Sentinel cost components should we compare against Wazuh?
Compare the Sentinel side by component: analytics ingestion, commitment tiers, retention beyond the included period, data lake charges and any export costs. On the Wazuh side, compare servers or cloud instances, storage for indexed alerts and archives, network traffic, backup, staff time and support. Some costs are one-time, such as migration and rule rewriting, while infrastructure, storage and staff time recur. Ask Microsoft for the current rate card for your region, and use your own daily volume and retention target to build both models side by side.
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 a Sentinel-to-Wazuh comparison, we start from your actual daily volume, retention and data sources so the cost components can be priced against your environment rather than a generic estimate.
How we scope
- We confirm daily ingestion volume, retention periods and the Sentinel tables and connectors in use today.
- The written scope lists the Wazuh components, OpenSearch nodes, storage and endpoints that the engagement covers.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work begins.
How we build
- We deploy the Wazuh indexer, server, dashboard and agents using the installation method your environment requires.
- We size the OpenSearch storage tiers and the Wazuh server cluster for the volume and retention agreed in scope.
- We configure SSO, role-based access and TLS, and test detections against sample events from your own sources.
How we hand over
- You receive architecture, sizing, configuration and runbook documentation covering each deployed component.
- We document the rule mapping from your existing Sentinel analytics rules to Wazuh rules, including gaps to confirm.
- Handover includes patch and upgrade procedures for the Wazuh 4.14 line and the OpenSearch maintenance schedule.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the fixed-scope work closes.
- Retainers can cover patching of Wazuh and OpenSearch releases, backup checks and access reviews on a schedule you set.
- Ask for the support scope, response expectations and exclusions in writing so you can compare it with your current Sentinel contract.
