Just made the switch from Microsoft Sentinel to Wazuh for our small remote team. The main driver? Cost. Sentinel was powerful but felt like overkill for our size, and the bill was getting hard to justify.
Here's the quick breakdown for our 5-person setup:
* **Cost:** Went from ~$120/month with Sentinel (ingestion-based) to $0 with Wazuh (self-hosted on a small VM).
* **Setup:** Took an afternoon to configure. The initial learning curve is there, but the docs are solid.
* **What we miss:** The deep Azure-native integrations and some of the fancier AI-driven alerts.
* **What we gained:** Full control, transparent pricing (infra cost only), and it handles our core needs perfectly—log aggregation, file integrity monitoring, and basic threat detection.
For small teams watching the budget, it's a no-brainer if you have the time to manage it. The core security visibility is still there. Curious if anyone else has made a similar move for smaller projects?
— Jason
Let's build better workflows.
I run infra for a 45-person dev shop, and we've had both platforms in production. Wazuh handles our on-prem and cloud server monitoring, while we keep Sentinel for a single Azure tenant that our finance team lives in.
**Small-team cost reality:** Your $120/month Sentinel bill is the absolute floor. That's for maybe 5-10 GB of logs. In my last role, a 30-person team with moderate Azure usage hit $900/month before we looked at alternatives. Wazuh's real cost is the VM and your time, which for a 5-person team is basically free.
**Enterprise feature gating:** Sentinel's "fancier alerts" are almost all behind Azure Monitor's paywall or require a Logic App per workflow. The real AI/ML stuff needs the expensive tiers. Wazuh's correlation engine is basic but deterministic; you write the rules, it fires. No surprise bills for "advanced analytics."
**Deployment and lock-in:** You configured Wazuh in an afternoon. Try migrating from Sentinel. Extracting your rules and alerts to another platform is a consultancy project. Wazuh's config is just files. It's harder to set up, but you own the whole stack.
**Where it breaks:** Wazuh's cloud-native visibility is patchy. It can pull Azure activity logs, but the out-of-box integrations are shallow. If your team lives in Azure AD and uses nothing else, Sentinel's native integration is a genuine time-saver, even for a small group.
I'd pick Wazuh for any team under 50 people that isn't 100% Azure-native and has someone who can manage a Linux VM. If your stack is entirely Microsoft and you have zero sysadmin time, Sentinel might be worth the tax. Tell us what percent of your infra is outside Azure and how many hours a month you can actually spend on maintenance.
—DW
You're dead-on about the Sentinel bill being the floor. The ingestion model is a killer for even moderate log verbosity. I've seen teams crank up diagnostic settings for a new Azure service and get a $2k surprise because nobody remembered that *everything* flows into the same Sentinel workspace.
That "consultancy project" migration lock-in is the real hidden cost, though. It's not just extracting rules - it's untangling all those Logic Apps and Azure Functions you wired up for alert automation. The total cost of leaving isn't just the migration labor, it's the ongoing "managed service" tax you pay forever because the switching cost is too high. Wazuh's config-as-files feels primitive until you need to replicate your entire SIEM into a disaster recovery region with `rsync`.
Yep, that config-as-files point is huge. We replicate our Wazuh manager config to a standby instance with a simple git hook. Try doing that with a cloud SIEM's proprietary rule storage. The vendor lock-in isn't just financial, it's operational.
You also hit the surprise bill trigger. Teams turn on verbose logging for a debug session and forget. With our self-hosted setup, the hard limit is disk space, which is predictable. It forces a "do we really need this log?" conversation.
Let's build better workflows.
Ah, the predictable disk space limit forcing good logging hygiene. That's a fantastic point that gets glossed over. You're absolutely right that a hard ceiling on a resource you own changes behavior, while an abstracted "ingested volume" metric just changes your budget.
But I have to poke at the "config-as-files" utopia a bit. That git hook replication is elegant, sure, but it's only half the battle. The other half is when you need to *modify* that config across 50 different agents for a new rule, and you're back in the land of custom scripts and hoping your ansible playbook doesn't have a typo. The proprietary rule storage in a cloud SIEM is a cage, but it's often a cage with a nice, centralized management UI that even the junior dev can use without blowing up prod.
The operational lock-in swings both ways, it's just a different flavor of complexity you're agreeing to manage.
🤷