Hey everyone, been lurking for a bit but this is my first post. I'm a junior DevOps engineer, and my team is currently looking at SIEM solutions. We're a hybrid environment with on-prem Active Directory and a growing Azure cloud footprint (VMs, AAD, some containers). We're trying to get a handle on security monitoring and threat detection.
I've been tasked with doing some initial comparisons, and right now, Exabeam and Azure Sentinel are the two frontrunners. I understand Sentinel is native to Azure, which seems like a huge plus for our cloud side, but I'm worried about the on-prem AD logs and potential cost creep.
From a practical, operational standpoint, I'm trying to figure out:
* How complex is the initial setup and log ingestion for each, especially for hybrid sources?
* What does the day-to-day look like for creating detection rules? I've heard Sentinel uses KQL, which is a bit like learning a new query language.
* How's the integration with other DevOps and CI/CD tooling? We use GitHub Actions and are starting with Kubernetes.
A simple example would be super helpful. Like, if I wanted to alert on a user account being created in on-prem AD and then used to log into an Azure resource within a short time frame, how would that detection rule be built in each platform?
Also, any gotchas on pricing models? Sentinel's pay-per-GB for ingestion vs. Exabeam's user-based licensing is a bit confusing when you have both human and service accounts.
Just trying to move beyond the marketing sheets and understand what it's actually like to live with these tools. Thanks in advance for any insights!
Learning by breaking
Senior security engineer at a mid-size SaaS shop (about 500 seats, heavy hybrid AD/Azure, also run self-hosted Kafka and a small EKS cluster). We put both Exabeam and Azure Sentinel through a three-month eval in 2023 and eventually ran Sentinel in production alongside a legacy Exabeam instance for a specific on-prem compliance carve-out. Here's the concrete breakdown from that eval.
- **Pricing structure and hidden cost creep**
Sentinel charges by data ingestion ($2-5/GB depending on commitment tier) plus Log Analytics workspace retention (default 30d free, then $0.10/GB/mo). If you're generating 50 GB/day from AD and Azure activity, that's roughly $3000-7500/mo in ingestion alone before any analytics rules or UEBA add-ons. Exabeam Cloud is per-user, roughly $4-8/user/mo depending on the tier (Advanced vs. Enterprise), with an on-prem connector license fee (~$500-1500/mo per collector). For 500 users, Exabeam could be $2000-4000/mo, but that includes user behavior analytics (UBA) and predefined correlation rules. The hidden trap with Sentinel: every custom log source (e.g., IIS, Windows Event Forwarding, custom syslog) that you pipe into Log Analytics counts as data ingestion, even if you only query it once a month. Exabeam's per-user pricing makes cost predictable, but you pay for the full user count even if only a subset is monitored.
- **Ingestion complexity for hybrid AD/Azure**
Sentinel is trivially native for Azure sources - an Activity Log data connector is a one-click enablement. For on-prem AD, you need the Azure Monitor Agent (AMA) installed on domain controllers or a Windows Event Collector, which sends Security Events to a Log Analytics workspace. Expect 1-2 weeks to tune forwarding rules to avoid flooding your workspace with verbose events (e.g., Event ID 4663 for every file access). Exabeam requires an on-prem collector appliance (usually a Linux VM or Docker container) that pulls logs from your domain controllers via Windows Event Log or WEF. The collector compresses and forwards to Exabeam Cloud. Configuring the collector's lookback and dedup settings took us about 3 days per site, but after that it was stable. For Azure AD audit logs, Exabeam uses the Graph API connector - same as Sentinel, but Sentinel's nested connector (Azure AD Identity Protection logs) gave us better coverage out of the box.
- **Detection rule creation and day-to-day operations**
Sentinel runs on KQL, which is a full query language - powerful but has a learning curve. For your example of alerting on an AD user account creation followed by an Azure login, the KQL looks like this:
```kusto
let ADCreate = materialize(
SecurityEvent
| where EventID == 4720
| project TargetUserName, TimeGenerated, Account = TargetSid
);
let AzureLogin = materialize(
SigninLogs
| where ResultType == 0
| project UserPrincipalName, TimeGenerated, IPAddress
);
ADCreate
| join kind=inner AzureLogin on $left.TargetUserName == $right.UserPrincipalName
| where AzureLogin.TimeGenerated between (ADCreate.TimeGenerated .. (ADCreate.TimeGenerated + 1h))
| project-away Account
```
That takes maybe 15 minutes to write if you know KQL, but you also need to set up a scheduled analytics rule (frequency, lookback window) and deal with false positives (e.g., sync from identity federation). Exabeam has a rule builder UI with drag-and-drop conditions (user attribute, event sequence, time window) - much faster for junior operators, but you're limited to what the platform exposes. Exabeam's UBA also surfaced anomalies (e.g., a user creating an AD account and then logging in from a new geo) without writing any rule - that was their killer feature for us.
- **Integration with DevOps / CI/CD tooling**
Sentinel exposes a full REST API and has native ARM/Bicep templates and Terraform resource definitions. You can version-control analytics rules as KQL files and deploy them via GitHub Actions with the Azure CLI or PowerShell modules. We automated new rule deployments into a staging workspace, tested against a 24-hour log replay, then promoted to production. Exabeam has a REST API (v2, reasonably well documented) for rules and incidents, but no native Infrastructure-as-Code support. We ended up wrapping the API calls in a Python script that ran as a GitHub Action step - it works but the response format changes more often. For Kubernetes, Sentinel integrates with Azure Arc and Container Insights to bring in audit logs from AKS directly. Exabeam can ingest container logs via a Fluentd or Filebeat forwarder, but correlation with AD requires additional log field normalization.
**My pick**: For a hybrid AD/Azure environment with a junior team and existing Azure investment, go with Azure Sentinel - but only if your data ingestion budget is under ~30 GB/day. Above that, the cost variability becomes a liability and Exabeam's flat per-user pricing wins. If you don't know your daily log volume yet (common for first SIEM), spin up Sentinel with a Log Analytics workspace and a free trial (31 days of 5 GB/day free), then measure. For the on-prem AD logs, plan on 1-2 weeks of tuning before you trust the alerts.
What's your estimated daily log volume from AD and Azure? And do you need UBA out of the box, or are you comfortable writing custom KQL rules? Those two answers will make the call clean.
numbers don't lie
That's a really important point about custom log sources in Sentinel. It's easy to get caught out if you're not modeling your data volumes carefully from the start. You mentioned IIS and Windows Event Forwarding, and I'd add that security appliances can be another big, unexpected contributor.
Your note about Exabeam including UBA and rules in its per-user price is also key for a fair comparison. In Sentinel, you often find yourself layering the cost of Logic Apps, Azure Functions, or Sentinel SOAR features on top of the base ingestion to get similar automated response capabilities. That per-user model can definitely simplify budgeting for mid-size teams.
Keep it real, keep it kind.
Oh yeah, the appliance logs are a silent budget killer. We had a similar shock with our Palo Alto firewall logs in Sentinel. What looks like a trickle in the console can suddenly be 30 GB a day once you turn on threat logging, and Sentinel doesn't discriminate between a verbose security event and a simple heartbeat.
The per-user pricing simplification is a double-edged sword, though. It's great for headcount budgeting, but you have to be careful you're not paying for dormant or service accounts. If your AD has 1000 objects but only 300 active human users, that model gets fuzzy fast. Exabeam's sales team was really helpful in modeling that for us.
Spreadsheets > opinions
You're right about the per-user pricing getting fuzzy, but I think that's a problem with any user-based model, not just Exabeam. It shifts the accounting burden from data ops to identity management. Now you're in a constant audit cycle with HR to deprovision accounts fast enough to trim costs.
We had a similar issue with a SaaS product that charged per "named user." The finance team loved the predictability until we had to explain why our bill spiked after an onboarding wave of 100 contractors who were all gone in 90 days. The lag in cleaning up AD objects meant we paid for them for an extra quarter.
The real question is whether Exabeam's support helped you build a process to exclude service accounts from the count, or if they just gave you a one-time discount to close the deal.
Your CRM is lying to you.