Our organization is currently evaluating Lacework as a potential central platform for security and compliance monitoring across a multi-account AWS environment, which currently stands at over 100 accounts and is expected to scale. The primary objective is to consolidate and rationalize alerting to reduce noise and operational fatigue, while ensuring critical findings are actioned appropriately.
I have conducted a preliminary analysis of Lacework's capabilities against our requirements, but I am seeking insights from practitioners who have implemented it at a similar scale. My core concerns are as follows:
* **Alert Routing & Hierarchical Structure:** With accounts spanning multiple business units and environments (prod, dev, staging), a single, flat alerting channel is untenable. What is the recommended strategy for mapping Lacework alerts to specific on-call teams? Is the primary method through integration with existing ticketing systems (e.g., ServiceNow, Jira), or are you leveraging the platform's native capabilities to segment by AWS account, resource tag, or specific policy violation?
* **Policy Customization & Noise Reduction:** The out-of-the-box policies are comprehensive but can generate significant volume. For those with large deployments, what has been your approach to policy tuning? Are you creating custom policies based on your specific compliance frameworks, and how effective has the policy exception process been for handling acceptable deviations?
* **Cost Implications of Scale:** Lacework's pricing model is based on a combination of data ingestion and monitored cloud resources. At our scale, even minor per-resource costs aggregate significantly. Have you implemented specific filtering or data exclusion strategies at the account or resource level to manage costs without compromising security posture? What was the impact on alert efficacy?
* **Operational Workflow Integration:** How are you handling the lifecycle of an alert—from detection in Lacework, to assignment, through to remediation verification? I am particularly interested in any automation you've built to close the loop, such as triggering AWS Systems Manager documents or Lambda functions directly from Lacework alerts.
The theoretical documentation is clear, but I am looking for empirical data on pitfalls, performance at scale, and the actual administrative overhead required to maintain an effective alerting regime. Comparisons to a previous toolset or a multi-tool approach would also be valuable context.
I'm a cloud platform lead at a financial services company with around 130 AWS accounts under management. We use Datadog as our central observability platform for infrastructure, application, and security monitoring, having migrated from a mix of tools about three years ago.
**Enterprise Fit & Pricing:** Datadog is built for complex, multi-account environments but you must negotiate aggressively. List pricing is opaque and high; typical enterprise discounting can bring it to 60-70% off. The real cost is in indexed logs and analyzed spans, not hosts. For 100+ accounts, you're looking at a six-figure annual commitment minimum, but it consolidates multiple point tools.
**Alert Routing & Structure:** The native capabilities handle this well. You define service-level tags (like `env:prod`, `team:payment`, `aws_account:123456789012`) on your data, then route alerts based on them to different Slack channels, OpsGenie schedules, or ServiceNow instances. We have over 200 monitored services with distinct routing, all from a single Datadog org. The hierarchy is tag-based, not account-based.
**Policy Customization & Noise:** You will spend 2-3 months tuning. Start with Datadog Security's out-of-the-box Cloud Security Posture Management (CSPM) and workload rules, but immediately suppress alerts by tag. For example, we suppressed `team:research` from all container runtime alerts. The platform allows custom policy logic, but the real win is using its observability data: you can alert only on security findings from hosts with a `critical` service tagged.
**Deployment & Integration Effort:** Rolling out the Datadog agent via a Terraform module across 100 accounts took one engineer two weeks. The larger effort was standardizing tags across all AWS resources and applications (another 6-8 weeks). The CSPM integration is agentless and requires a CloudFormation StackSet or Terraform to deploy a read-only IAM role; that's a one-day project.
I'd recommend Datadog if your team already uses it for APM or infrastructure monitoring and you can bundle security into your contract. If your sole need is security/compliance alerting without the observability suite, tell us your budget per account per month and whether you have a dedicated team for tuning.
null
> **Alert Routing & Hierarchical Structure:**
This was our biggest migraine during the Lacework rollout. Native capabilities for routing are shallow, honestly. You'll end up building everything you need inside a notification channel integration. We used ServiceNow, and the key was mapping Lacework's "event source" field (like `AWS_CloudTrail`) combined with a mandatory `BusinessUnit` tag we enforce on all AWS resources. This let us route dev anomalies to a dev-secops queue and prod policy violations straight to the on-call pager.
> **Policy Customization & Noise Reduction:**
The out-of-the-box policies are a fantastic starting point, but you will turn off about 40% of them immediately, especially in non-prod. The real power is in the custom policies, but be warned, their query language has a learning curve and you'll need to dedicate a team member to tune them for a few weeks. Our biggest win was creating environment-aware policies: a "critical" finding in dev might just be a "low" info alert sent to a Slack channel, while the same finding in prod screams into PagerDuty. It cut our actionable alert volume by about 70%.
We ran a POC on Lacework last year for about 60 accounts, and the routing piece is exactly where it got messy. The native tagging and segmentation felt brittle for our scale.
We found the only viable path was to treat Lacework as a pure event source and push everything to our existing ticketing system. Like another commenter mentioned, you'll need to bake a strict tagging convention (business_unit, cost_center, env) into your resource provisioning upfront. The real trick was using the Lacework APIs to pre-filter and enrich alerts before they hit the ticketing middleware, otherwise the volume was overwhelming.
On the policy side, start with a whitelist approach, not a blacklist. We enabled maybe a dozen core policies globally and then built custom ones slowly per business unit. The noise from the default set was instant fatigue. Their query language is powerful but has a real learning curve. Did your team build any internal tooling to manage the policy lifecycle?
✌️
Interesting you're focusing on the platform's native capabilities for routing. That's putting a lot of faith in their roadmap. In my experience, any vendor's "native" solution for complex hierarchies is, at best, a thin veneer over their API. You'll end up building the logic yourself anyway, just within their walled garden.
The real question is whether you can maintain a consistent tagging taxonomy across all 100+ accounts *before* you turn on the firehose. If your resource tagging discipline is poor, no platform's routing logic will save you, and Lacework will just be an expensive, noisy data source.
You mentioned "rationalize alerting to reduce noise." That's the core of it. The out-of-the-box policies are a trap. They're designed for vendor checkbox demos, not for a scaled operation. You'll spend the first six months tuning them out, which is essentially paying them to learn your own environment. Start with everything off and build custom policies from the ground up, aligned to your actual incident response playbooks. Otherwise, you're just buying a fancy dashboard for alert fatigue.
Data skeptic, not a data cynic.
We're at a similar scale (120+ accounts) and ended up on a hybrid approach for routing.
We treat Lacework as the event source, but we built a lightweight middleware in Python (using the Lacework APIs) to handle enrichment and routing logic. This sits between Lacework and our ServiceNow instance. The key was querying our internal CMDB to pull in business unit and team data *before* creating a ticket, since our AWS tagging was too inconsistent to rely on alone.
> **Policy Customization & Noise Reduction**
Our rule of thumb was to start with *zero* policies enabled. We then enabled a curated set of 5-10 "universal" high-severity policies (like brand new IAM principals) that went to a central SecOps team. Everything else was built as a custom policy tied to a specific business unit's risk profile, after consulting with them. It was slower, but noise dropped by like 80% from the initial POC where we used the default policy pack.
Data is the new oil - but it's usually crude.
Starting from zero policies is such a smart idea, I wouldn't have thought of that. It seems obvious once you say it, but everyone's instinct is to turn everything on.
How do you manage that curation process with the business units? Do you have a formal request form, or is it more like a series of workshops? We struggle with getting teams to define their own risk profiles.