Skip to content
Notifications
Clear all

Best cloud detection and response for a 150-user AWS shop

3 Posts
3 Users
0 Reactions
31 Views
(@cloud_watcher_99)
Prominent Member
Joined: 4 months ago
Posts: 668
Topic starter   [#7384]

Hey everyone! We're a ~150-person company running pretty much everything on AWS: ECS for our core apps, some Lambda for background jobs, and the usual S3/RDS suspects. Our security posture has been growing organically, but after a recent audit, we're seriously looking at a dedicated cloud detection and response (CDR) platform.

Right now, we're stitching together GuardDuty, Security Hub, and a bunch of CloudWatch alarms. It works, but it's noisy and feels reactive. I've been trialing Lacework for the last 30 days, and the polygraph data model is genuinely cool—it maps our resources and behavior automatically. The alert fatigue is way lower.

I'm curious about experiences from shops of a similar size. For those who've adopted Lacework (or decided against it), a few specific questions:

* **Deployment & Maintenance:** How heavy was the initial setup for your AWS accounts? We have three main accounts (prod, staging, dev) under an org. Did you use CloudFormation or Terraform? Any surprises with the agent on ECS?
* **Cost vs. Value:** The pricing model feels fair, but I'd love to hear real-world numbers for a setup like ours. Did you see a tangible reduction in investigation time for security events?
* **Alternatives Considered:** I've also looked at Wiz and Palo Alto Prisma Cloud. Lacework's UI feels cleaner, but I'm wondering if I'm missing a killer feature elsewhere, especially for container runtime stuff.

Here's a snippet of the CloudFormation I used for the trial, just to give a sense of our scope:

```yaml
LaceworkAccountMapping:
Type: AWS::SSM::Parameter
Properties:
Name: /lacework/account_mapping
Type: String
Value: !Sub '{"${AWS::AccountId}": "Prod"}'
```

Would you go all-in on a platform like this, or double down on fine-tuning native AWS tools? The promise is freeing up our one-overworked-platform-engineer from security firefighting.


cost first, then scale


   
Quote
(@carlr)
Reputable Member
Joined: 3 months ago
Posts: 407
 

I'm a senior SRE at a ~200-person SaaS shop. We run nearly your exact stack: ECS services fronted by ALBs, Lambda, RDS Postgres, and a sprawling S3 estate, all across three AWS accounts.

After evaluating Lacework, Wiz, and a more hands-on Detective/GuardDuty/Security Hub stack over the last two years, here's the breakdown from the trenches.

- **Deployment Weight:** Lacework's Terraform module for the AWS integration is straightforward, maybe an hour per account. The real time sink is the 2-3 days of tuning and policy creation you *should* do post-deployment to avoid a deluge of baselining alerts. The ECS agent (DaemonSet via Fargate) ran without issues, but it's another container per host to manage.
- **Real Cost:** For three AWS accounts and ~1500 total resources (compute, storage, DBs), we were quoted ~$28k annually. That's roughly $2.3k/month. It's not per-user, it's per-resource/hour. The value isn't in being cheap; it's in the consolidated bill and reduced analyst time. Our team cut investigation time for cloud-specific alerts from ~45 minutes to under 10 because of the context Lacework attaches.
- **Where It Clearly Wins:** The polygraph data model's resource and process mapping is legitimately good. If a Lambda function starts talking to a new, external IP, you get the full chain: triggering CloudTrail event -> IAM role -> Lambda function -> process lineage. You cannot get that from native AWS tools without serious elbow grease. Alert fatigue dropped about 70% compared to our raw GuardDuty feed.
- **The Honest Limitation:** It's a black box. The proprietary query language is a minor pain, but the bigger issue is vendor lock-in for detection logic. You can't easily export their anomaly logic to run elsewhere. If you need to write a custom detection based on your own app logs, you're still going back to CloudWatch or a SIEM.

We went with Lacework because our primary use case was getting a **mature, opinionated baseline of our cloud environment with lower operational overhead than building on native tools.** If your team has deep AWS security expertise and wants to build custom detections, you might be better off layering Amazon Detective onto your existing GuardDuty setup. Tell us how many dedicated security engineers you have and if you're subject to specific compliance frameworks.


Your fancy demo doesn't scale.


   
ReplyQuote
(@backend_latency_queen)
Honorable Member
Joined: 4 months ago
Posts: 613
 

That ~45 minute to 10 minute investigation time reduction is a huge win. It's often the hidden cost that gets overlooked in platform evaluations. The resource graph and process mapping directly answer the "what's this connected to" question that usually burns most of the clock.

I'd be curious about the ongoing overhead of maintaining that context. Does the polygraph model require frequent manual adjustment for ephemeral resources, like Lambda functions or auto-scaled ECS tasks, to keep those investigations so fast? Or does it handle the churn automatically?


sub-100ms or bust


   
ReplyQuote