I've been operating Lacework across a multi-account AWS organization for the past 18 months, and I believe the community would benefit from a detailed, operational review. Our setup comprises 30 AWS accounts under a single organization, spanning development, staging, and production environments, with a mix of containerized workloads on EKS and traditional EC2 instances.
The initial deployment via Terraform was relatively straightforward, leveraging Lacework's provided modules for the organization-level integration. The critical configuration was the CloudTrail and Config integration at the management account level, which then propagated findings across all linked accounts. However, we encountered several non-trivial operational considerations:
* **Agent vs. Agentless Coverage:** We opted for a hybrid approach. The agentless Cloud Security Posture Management (CSPM) provides the foundational visibility across all 30 accounts without deployment overhead. For runtime security on our critical production workloads (approximately 2000 EC2 instances and EKS nodes), we deployed the Lacework agent. The data volume and cost implications between these two modes are significant.
* **Cost Structure Analysis:** The pricing model is complex. Costs are driven by:
* Number of cloud accounts monitored (CSPM).
* Number of agents deployed (runtime).
* Data volume for activity logs (specifically for container registry and cloud audit log analysis).
We observed a 40% cost increase in month two as we fully enabled Kubernetes audit log collection, which was not entirely anticipated. Careful tuning of log filtration is essential.
* **Alert Tuning and Noise Reduction:** The default policies generated substantial alert volume, particularly in development environments. We implemented a multi-tiered policy suppression strategy using Lacework's Terraform provider. Below is a snippet of our approach to suppress benign alerts in non-production accounts:
```hcl
resource "lacework_alert_channel" "slack_prod" {
name = "Production Alerts"
type = "Slack"
enabled = true
data {
slack_url = var.slack_webhook_url_prod
}
}
resource "lacework_alert_rule" "suppress_dev_aws_scan" {
name = "Suppress AWS CSPM Alerts for Dev"
description = "Only alert on HIGH severity in dev accounts"
channels = [lacework_alert_channel.slack_prod.id]
severity = ["High"]
event_categories = ["Compliance"]
resource_groups = [lacework_resource_group.dev_accounts.id]
}
```
**Performance and Operational Overhead:** The platform's backend scales transparently, which is a benefit. However, the agent memory footprint on our EKS nodes averaged 85MB, with a CPU utilization of 0.05 vCPU cores per pod. This is non-negligible at our scale and must be factored into capacity planning. The console UI can become sluggish when building complex queries across the entire 30-account dataset; we increasingly rely on the API for automated reporting.
**The Bottom Line for Large Organizations:** Lacework provides consolidated visibility that is difficult to achieve with native tools. Its strength is in correlating findings across the cloud control plane (CSPM) and the workload runtime. The primary pitfalls are financial and operational: you must actively manage the scope of data ingestion, aggressively tune alert policies from day one, and model costs against your specific account and resource count. For a 30-account setup, I would strongly recommend a phased rollout, beginning with CSPM only, followed by selective agent deployment, with continuous budget monitoring.
I am happy to share specific benchmark data on query performance or our full Terraform module structure for the organizational integration if there is interest.
Regards,
Luke
Measure everything.