Skip to content
Notifications
Clear all

We're evaluating security tools - does Sumo's SIEM hold up?

2 Posts
1 Users
0 Reactions
5 Views
(@cloud_ops_amy)
Estimable Member
Joined: 5 months ago
Posts: 128
Topic starter   [#9858]

Hey everyone! Our team is currently in the evaluation phase for a cloud-centric SIEM solution, and Sumo Logic is on the shortlist. We're primarily an AWS shop running a mix of EKS workloads, Lambda functions, and a ton of CloudTrail logs. I've been tasked with digging into the practical, day-to-day aspects beyond the sales sheets.

From my initial tinkering, the query power is impressive. The ability to correlate Lambda execution errors with suspicious IAM events in a single dashboard is a big win. However, I'm curious about the operational overhead and cost predictability at scale.

Some specific things I'm hoping folks with hands-on experience can shed light on:

* **Ingestion & Parsing:** How much tuning did your parsing rules require for custom app logs? Was it a constant battle, or did it settle down?
* **AWS Native Integration:** They tout deep AWS integration. In practice, does using their CloudFormation stacks or Terraform provider for log source onboarding work smoothly, or are there hidden gaps?
* **Cost Drivers:** We're very cost-conscious. Beyond the obvious (data ingestion volume), what are the less-discussed cost factors? For example:
* Query performance on retained data (scan costs).
* Dashboard refresh frequency for real-time monitoring.
* Alerting volume and complexity.
* **Threat Intel Feeds:** How useful and actionable have you found their built-in threat intelligence? Does it integrate well into your alert workflows?

I'm also wondering how it stacks up against building something more piecemeal with open-source tools (e.g., OpenSearch, Falco) versus other managed services. The appeal is a unified platform, but I want to make sure we're not trading flexibility for a black box.

If anyone has architecture examples, especially with Terraform for setup, or real-world cost breakdowns for a mid-sized setup (~500 GB/day), I'd be incredibly grateful. What were the "gotchas" you didn't see coming?

-- Amy


Cloud cost nerd. No, I don't use Reserved Instances.


   
Quote
(@cloud_ops_amy)
Estimable Member
Joined: 5 months ago
Posts: 128
Topic starter  

On the parsing front - it does settle down, but the initial setup for custom app logs was more work than I expected. Their built-in parsers for AWS services are solid, but anything custom (like an internal microservice logging in a weird format) will need regex tuning. We had to iterate about 3-4 times over a couple weeks before things stabilized. The good news is once you get the grok patterns right, it's pretty hands-off.

As for the AWS integration - their CloudFormation stack for log source onboarding works fine for basic setups, but the Terraform provider has some gaps. The resource for configuring scheduled searches is a bit clunky, and you can't manage all the parsing rules via TF alone. We ended up with a hybrid approach: TF for infrastructure, Sumo's API for a few specific configs.

Cost predictability is the real trap though. The ingestion volume is the obvious one, but the hidden cost driver is query performance. If your team runs heavy ad-hoc queries across long time ranges, it can spike your Compute Capacity Units. We had one analyst who'd run "select *" across 30 days of CloudTrail logs and that single query cost us more than our daily ingest. You might want to ask about the "flex" vs "fixed" capacity pricing model and how they calculate query credits.


Cloud cost nerd. No, I don't use Reserved Instances.


   
ReplyQuote