Amazon Security Lake: What It Gives You, What It Doesn't

Amazon Security Lake collects, normalizes and stores AWS security data in a central, queryable layer. It doesn't detect threats, investigate them or respond to them; that work still belongs to whatever tool or team you point at the lake.

Teams turn to Security Lake because turning it on is easy. Point CloudTrail, VPC Flow Logs and the Security Hub CSPM feed at it, and you can have terabytes of Open Cybersecurity Schema Framework (OCSF) Parquet sitting in S3 within weeks. The harder question comes later, when someone asks "did anything touch that bucket last Tuesday?" and the query that was supposed to catch it was never scheduled.

For an organization running mostly on AWS, that's still a good floor to build on. This article covers what Security Lake does natively, the detection, context and investigation work that stays with your team, and how to decide whether to build, subscribe to, or hire that layer.

TL;DR:

• Security Lake covers collection, normalization and storage. For AWS source version 2, it normalizes native logs and findings to OCSF 1.1.0 and stores them as Parquet using Apache Iceberg as the table format, landing them in per-Region S3 buckets and handing them to subscribers. AWS describes subscriber tools as the place where findings are generated, correlated and turned into alerts.
• After setup, teams still build custom-source OCSF mapping, scheduled detections, identity and asset enrichment, and response automation on top of the lake. Two published examples illustrate this separation: Siemens paired it with Cribl and Splunk, and Torc paired it with Datadog.
• Budget for ingestion and normalization, S3 retention, applicable CloudTrail charges, querying, pipelines, and the analytics or managed-service layer. Their relative costs depend on log volume, retention, query patterns, duplicate collection and the tools you select.
• As the market separates storage from investigation, choose who will own investigation. In-house detection-as-code, a SIEM subscriber or a managed service determines how much security-expert time you save.

What Security Lake does natively

Security Lake automates sourcing, aggregation, normalization and data management for a fixed set of AWS logs inside your own account, and that part works. The AWS user guide describes the service as collecting from integrated AWS and third-party services, converting data to Apache Parquet and OCSF, and partitioning it for query efficiency; a 2024 update moved AWS source version 2 to OCSF 1.1.0 with Apache Iceberg as the table format.

The native list is short: CloudTrail management and data events (S3 and Lambda), EKS audit logs, Route 53 resolver query logs, Security Hub CSPM (AWS's rebranded aggregation service, which carries its own posture checks plus findings that GuardDuty, Inspector and Macie feed into it), VPC Flow Logs and AWS WAFv2 logs. AWS AppFabric normalizes SaaS audit logs such as Jira, Slack and Smartsheet to OCSF JSON, then delivers them to Security Lake through Amazon Data Firehose.

Data-access subscribers receive notifications about new S3 objects and retrieve the permitted data directly; query-access subscribers receive access to cataloged tables through Lake Formation and query them with a compatible engine, commonly Athena but also Redshift Spectrum or Spark SQL. Either way the consumer must read Parquet and OCSF.

Custom sources, up to 50 per account, must arrive in a compliant OCSF (1.3 or earlier) Parquet format and meet the lake's partitioning and delivery requirements. A pipeline product such as Cribl can perform that transformation on a customer's behalf, so the mapping work doesn't always fall to the customer directly.

In US East (N. Virginia), Security Lake charges $0.75 per GB for CloudTrail logs, from $0.25 per GB for other logs and $0.035 per GB for normalization, plus standard S3 storage. AWS's own worked example comes to $693.76 per month for 512 GB of CloudTrail and 1,024 GB of other logs, assuming a CloudTrail organization trail already exists.

A second AWS example shows that creating a new organization trail where individual account trails already deliver the same management events can add roughly $3,740 a month in duplicate CloudTrail charges, depending on your existing trail configuration.

Security Lake itself doesn't charge ingestion or normalization fees for third-party and custom data, but the storage, transformation pipelines and downstream services that data needs can still add up.

What it does not do

Security Lake leaves detection, correlation, alerting and response to the tools that subscribe to it. AWS never draws that boundary in one sentence, but its guidance consistently places detection in the tools that subscribe to the lake. Its FAQ positions the lake as something analytics tools access "for threat detection, investigation, and incident response," and in its file-integrity-monitoring walkthrough a Lambda generates the finding before the lake ingests it. 

Jon Oltsik, then of Enterprise Strategy Group, wrote in TechTarget in June 2023 that Amazon's product category was a data lake. SIEM analytics remained the customer's responsibility: customers must "bring your own security analytics." Oltsik's framing is commentary from 2023; AWS's own current documentation still backs the underlying point: without scheduled Athena queries, EventBridge integration or a SIEM subscriber, the lake stores data without analyzing it.

Security Lake doesn't execute containment actions itself. Response requires a separate workflow or service that evaluates findings or query results and invokes authorized actions; AWS's Automated Security Response on AWS is one documented option, and it uses Security Hub findings to trigger predefined remediation workflows.

Siemens sends security data from its AWS accounts into Security Lake, and Cribl forwards the most relevant slice to Splunk, where the threat detections run. Torc Robotics sends data from its Regions and accounts into Datadog as its cloud SIEM. These architectures can reduce what the SIEM must ingest, but they still require forwarding logic, SIEM configuration and ongoing detection ownership above the lake.

The work that stays with your team

Four categories of work remain after setup, and AWS documentation quantifies none of them. The division of labor is consistent across sources; the hours are not, so read the vendor figures below as positions from companies that sell the relevant layer.

1. Mapping custom sources to OCSF

For sources without an existing compatible integration, someone must define, validate and maintain the OCSF transformation. AWS's configuration-driven extract, transform and load (ETL) reference solution targets OCSF 1.1 and runs on Glue or EMR Serverless once you supply mapping and configuration files. It's a separately deployed accelerator layered on top of Security Lake, and AWS recommends checking existing community mappings first.

Existing vendor or community mappings can reduce the work, but they still need validation against your own source data. Source-specific fields can be preserved under unmapped, though queries and detections may then need source-specific logic to interpret them. Practitioners discussing Security Lake in community forums have described a similar split: mapping new log sources into OCSF can be a lot of work, though querying is fast once the data lands in Parquet.

2. Writing and scheduling detections

Nothing in Security Lake schedules a query or raises an alert on its own; your team writes and maintains that logic. An AWS cross-service correlation walkthrough shows teams moving from ad hoc CloudWatch queries to scheduled Lambda checks and broader EventBridge and Step Functions orchestration. But it opens by recommending native detection services and GuardDuty Extended Threat Detection first, and treats the custom pattern as one implementation option layered on top of Security Lake.

Lake-based checks need their own query engine, permissions, result handling and alerting workflow.

Every query also has to respect the schema. AWS source version 2 tables partition by time_dt, region and accountid; version 1 partitions by eventDay, region and accountid; custom sources use their own documented S3 layout, which can differ from both. Once retention is configured, each query needs a time filter. 

OpenSearch takes a different path, adding its own detector and rules engine once you have brought logs across into its indices.

3. Adding identity and business context

Logs and findings often already carry identity and resource attributes. Ownership, approved behavior, data sensitivity and other business context still need additional sources and maintained enrichment.

Tenzir turns configuration management database (CMDB) exports into lookup tables keyed by IP or asset ID that write hostname, owner and zone into OCSF objects. Panther can enrich CloudTrail and Security Lake events with TrailDiscover's event descriptions, MITRE ATT&CK context, incident references and security implications. OCSF added an open-source intelligence (OSINT) profile for threat-intel enrichment.

Who a user is, whether 2am activity is normal for them, and which bucket holds regulated data are questions the lake preserves evidence for but does not resolve. This context, not the query engine, is what turns a result set into a verdict.

4. Triage, investigation and response

Security Lake doesn't itself provide a staffed investigation queue, but AWS-native integrations automate parts of the querying and investigation work. AWS documents a Bedrock-powered agent that generates and executes Athena SQL from natural language and surfaces response playbooks, though a person still reviews the results and decides which playbook applies.

Quick (formerly QuickSight) serves responders who do not write SQL. Amazon Detective pulls CloudTrail management events, VPC Flow Logs and EKS audit logs from the lake up to source version 2, though it works from that raw log data directly, without its own aggregation layer. 

Practitioner guides assemble EventBridge and Step Functions pipelines that isolate instances, revoke keys or quarantine buckets, and AWS recommends validating each remediation in a non-production account and Region before enabling it to run automatically.

Nothing in the AWS-native stack staffs a queue against arbitrary lake query results or decides which Athena result is an incident. AWS Security Incident Response, the managed investigation service, triages GuardDuty findings and third-party threat findings that reach Security Hub specifically, not Security Hub's CSPM or posture findings. Its documented inputs don't extend to arbitrary Security Lake query results.

The table below maps each layer above the lake to what it covers and who still owns the work:

These approaches either query Security Lake in place or copy selected data into another analytics store (Datadog's integration, for instance, copies the logs into its own platform); confirm which applies before assuming the lake stays the system of record for investigation history.

Decision criteria: build, subscribe, or hire the layer above the lake

Evaluate Security Lake when centralized retention, native-source normalization and subscriber interoperability meet your requirements, typically in a multi-account AWS environment dominated by native AWS sources.

With Splunk, Datadog or another subscriber SIEM already in place, follow the Siemens pattern: land the high-volume data in the lake, forward the events required for detection and investigation, and keep detection where the security experts already are.

A team with detection engineers but no SIEM should budget for detection-as-code or Sigma plus scheduling infrastructure before counting on the lake for monitoring. It should also budget mapping hours for every non-native source.

As non-native telemetry grows, validate connector coverage, transformation effort and cross-source investigation before counting on the lake as more than a storage layer. The investigation layer still needs integrations and business context that the lake does not carry.

Organizations without around-the-clock queue ownership must decide who runs investigation and response on top of the store. The operating model determines who monitors, investigates and responds using the collected data: native-source mix drives the architecture, and queue ownership drives the recurring staffing or service cost.

Why investigation ownership matters

Separating storage from analytics creates an additional ownership decision. Security Lake deployments still force that choice.

Gartner researchers Andrew Davies and Angel Berrios wrote on May 21, 2026 that storing all data in a traditional SIEM "is becoming too expensive for some organizations" and advised pairing security data lakes with data pipelines for cost-effective storage, standardized threat hunting and security operations center (SOC) AI integration.

Anton Chuvakin's "decoupled SIEM" framing (one vendor building storage while another builds the detection and analytics layer) describes the decision a Security Lake deployment forces, and the debate around it suggests many teams still prefer integrated stacks.

Jack Naglieri, Panther's founder, frames the constraint as the human bottleneck in the investigation loop rather than the data or the models. The build path's real cost shows up after launch: your team owns OCSF mapping, detection scheduling, enrichment and the investigation queue for as long as the lake runs. Business context about users and assets, including which data is regulated, turns query results into verdicts and must be available wherever investigation happens.

The architectural shift is toward a data lake paired with an investigation layer that assembles that context, runs investigations and routes judgment calls to the experts accountable for the outcome. The result replaces a passive store waiting for a human-written query with an operating system for investigation.

For teams evaluating managed approaches, Daylight frames the category shift as changing the operating model beyond staffing efficiency. Earlier-generation MDR providers place people above the customer's tools to gather context and investigate escalations, a design that made sense when telemetry was narrower but keeps throughput tied to staffing and shift handoffs as cloud, identity and SaaS data expand.

In Daylight's framing, AI-native MDR changes that operating model, with a platform assembling telemetry, organizational and historic context and running investigations, while security experts handle ambiguous cases, response judgment and accountability. Other providers' automation, staffing and response authority vary by implementation and contract.

Daylight is a MASS company, meaning it offers managed agentic security services for Security Operations. It applies that operating model to

Daylight MDR, threat hunting and the Agentic Security Data Lake (an add-on, available exclusively to Daylight MDR customers, that extends retention and adds self-service search; MDR-only customers can still request searches from Daylight but don't get self-service access), with phishing and data loss prevention (DLP) coverage extending the same MDR investigation layer rather than running as separate tools.

Frequently asked questions about Amazon Security Lake

Does Amazon Security Lake replace a SIEM?

No. It's the retention and normalization layer underneath whatever actually analyzes the data. Most teams still pair it with a SIEM, OpenSearch, or a managed service to get from stored logs to an alert.

Do you still need a security expert with Security Lake?

Yes, but the work shifts shape. Your team, or a managed partner, spends that time on mapping, tuning, context and judgment calls on top of what the lake already gives you, rather than on building collection and storage from scratch.

Can Security Lake ingest data outside the native AWS log list?

Yes, up to 50 custom sources per account, but it won't do the conversion for you. Whatever you add has to land in Security Lake's OCSF/Parquet format already, whether that's your own pipeline, a vendor integration like Cribl, or a service provider doing it on your behalf.

What does Security Lake cost beyond the per-GB fee?

Budget for S3 storage and requests, querying and query-result storage, applicable data transfer, supporting AWS services, and your analytics or managed-service layer on top of the published per-GB rates. Collecting CloudTrail management events requires an organization trail, so check for duplicate event delivery before estimating that line item.

Who should turn on Security Lake first?

Teams already committed to AWS as their primary cloud, with a SIEM or detection layer either in place or budgeted, get the most value from turning it on early. Without that layer planned, the lake alone won't close any detection gap.