H3-INTEGRATION-03 · Tier B · 4/5 (extension)
AWS Security Lake. Useful, qualified, AWS-shaped.
OCSF — the Open Cybersecurity Schema Framework, the multi-vendor schema standard for security data — was the right idea with the wrong adoption economics. Mapping vendor logs to OCSF was tedious manual work that didn't survive procurement. AWS Security Lake changed the math for AWS-heavy shops. The change is real. It's also narrower than the marketing suggests.
Why it matters
The OCSF adoption economics changed.
Before Security Lake, deploying OCSF in production meant a do-it-yourself data lake. S3 buckets with partitioning, lifecycle policies, encryption. A Glue Data Catalog with OCSF schema definitions. Lake Formation governance, row-level security, column masking. Lambda or Firehose pipelines per source. Custom OCSF mapping code per vendor — Okta, CrowdStrike, Netskope, the long tail. Plus the maintenance burden when OCSF evolves or vendor schemas change. Realistic shape: 3–6 months of build time for two to three engineers, 20–40% of an FTE on ongoing maintenance, $300K–$600K in loaded year-one cost. Most security teams can't justify that as a line item.
AWS Security Lake (generally available since May 2023) is a managed service that does the build for you, for the AWS-native sources at least. Storage on managed S3 with OCSF partitioning. Auto-managed Glue catalog. Lake Formation integration tied to IAM. Automatic ingestion for AWS sources — CloudTrail (API activity), VPC Flow Logs (network traffic), Security Hub (finding aggregation), Route 53 Resolver (DNS queries), EKS audit logs. OCSF mapping handled by AWS for the native sources, and by participating vendors for the third-party integrations.
The cost shape moves accordingly. Setup measured in 1–2 weeks rather than months. Maintenance closer to 5–10% of an FTE. Infrastructure $3K–$7K per month. Year-one totals in the $50K–$100K range for the same mid-sized organization. That's a 60–80% reduction versus DIY, and a 90% reduction in time-to-value. The OCSF adoption barrier just got significantly lower for AWS-heavy shops. That part of the claim survives scrutiny.
How open is it, actually
Open at some layers. Locked at others. The boundary matters.
Three things are genuinely open. The OCSF schema itself is Apache 2.0 with community governance and multi-vendor participation — Splunk, Cloudflare, Palo Alto, AWS, others. The data format on disk is Parquet, the open columnar storage standard, with OCSF-compliant JSON structure on top — readable by any Parquet-compatible tool (DuckDB, Trino, Spark, Dremio). Query access goes through Athena (AWS-managed Trino), direct S3 access, or third-party integrations with standard SQL. The data is exportable. You can leave with it.
Three things are locked to AWS. Automatic ingestion is AWS-only — CloudTrail, VPC Flow, the rest of the native sources auto-normalize to OCSF, but non-AWS sources require third-party integration or custom code, and leaving AWS means losing the automatic normalization layer. Governance runs through AWS IAM and Lake Formation; access policies don't migrate to non-AWS platforms without manual recreation. The managed service itself runs in your AWS account but isn't portable to Azure, GCP, or on-premises environments.
The honest summary: Security Lake is more open than most vendor platforms and less open than fully DIY. The data is exportable; the operational surface around it isn't. The framework that helps here is multi-layer openness: the table format and schema can be open while the catalog, identity, and authorization layers remain proprietary. Security Lake is open at the storage and format layers, qualified-open at query, and AWS-locked at governance and ingestion. If your strategy assumes you stay in AWS, that's a clean tradeoff. If it assumes multi-cloud or AWS exit, the lock-in surface needs to be priced into the decision.
The "70+ integrations" claim, decomposed
Four tiers of integration. Only one of them is automatic.
Tier 1 — native AWS sources.
CloudTrail, VPC Flow, Security Hub, Route 53 Resolver, EKS audit logs. Enable Security Lake; AWS auto-normalizes to OCSF. No mapping code, no maintenance burden. The promise of "managed OCSF" applies here cleanly.
Tier 2 — partner direct-write integrations.
CrowdStrike (EDR), Okta (identity), Palo Alto Networks (firewall), Cisco (network), Zscaler (SSE), and others. The vendor writes OCSF-formatted data directly into your Security Lake, handling the OCSF mapping on their side. The promise applies — but with a catch. The vendor decides which OCSF event classes they support and how accurately they map fields. Integration quality varies meaningfully across this tier.
Tier 3 — "we support Security Lake" (marketing, not technical).
Some vendors claim Security Lake support but mean something thinner: they read from Security Lake (they query your data, they don't write to it), they have a Lambda function that drops files in S3 (not actually OCSF-formatted), or they're "planning to integrate" (vaporware). The verification step before relying on a Tier 3 claim: ask for a sample OCSF output, check field mapping completeness, confirm the vendor uses correct OCSF event classes. The pattern is common enough to make explicit.
Tier 4 — everything else (DIY required).
Internal applications. Niche security vendors without a Security Lake integration. On-premises infrastructure outside AWS. Legacy systems whose log format you can't change. For Tier 4 sources, the engineering effort returns to roughly DIY-OCSF-data-lake territory — custom mapping code, write-to-Security-Lake via API, ongoing maintenance. Security Lake doesn't solve the long-tail integration problem for non-participating vendors. Cribl, Tenzir, or custom code is still on the menu. The "70+ integrations" headline has to be read against your specific vendor stack: how much of it lands in Tiers 1–2, how much falls into 3–4.
Hidden costs
20–40% above the advertised pricing, on a recurring basis.
Three categories of cost don't show up in the Security Lake pricing page and tend to surprise security teams once production starts.
Third-party integration charges. Some vendors charge extra for Security Lake connectivity: "Security Lake connector is enterprise-tier only" (mandatory upgrade), "Security Lake write integration: $X per GB" (double-charging), "custom OCSF mapping is a professional services engagement" (consulting fees). The vendor lock-in pattern migrates to the integration layer — pay or lose Security Lake compatibility.
Data egress for non-AWS query engines. Athena queries inside AWS pay $5 per TB scanned with no egress. Querying Security Lake from Dremio, Trino-on-prem, or a hybrid analytics layer adds $0.09 per GB egress on top of the scan cost. Multi-cloud or hybrid architectures pay an egress penalty for the privilege of accessing their own data.
OCSF mapping quality gaps. A vendor writes to Security Lake but maps only 60% of OCSF fields, leaving the rest null or in vendor-specific extensions. Or maps to the wrong event class. Or undocumented extensions that can't be queried reliably. The consequence: you pay for Security Lake storage and still need a custom enrichment layer to make the data usable for the workloads you bought it for.
None of these are unique to AWS. They're the predictable surface where any managed-service economics meet the long tail of vendor heterogeneity. The pricing-page calculation is a floor, not a ceiling.
What this extends
H3-INTEGRATION-03, with the AWS-specific qualifications.
The anchor hypothesis on the research page reads: OCSF is gathering meaningful multi-vendor momentum, with 180+ organizations participating and ITU-T recognition landed in March 2026. The standardization trajectory is Tier A. The petabyte-scale production claims attached to it are weaker — Tier C-D in places, which is why the page currently carries a confidence reduction on the production-scale dimension while keeping the standardization-trajectory dimension at full confidence.
Security Lake sits inside that picture as the strongest production deployment vector for AWS-heavy environments. It validates a specific claim: that managed OCSF infrastructure can drop the adoption cost by roughly 60–80% versus DIY for the AWS-native portion of an organization's telemetry. It does not validate the broader claim that OCSF runs cleanly at petabyte scale across heterogeneous vendor sources; the integration-quality variance across Tiers 2–4 is exactly the place where the broader claim has its evidence gap.
What would change the answer. Independent measurement of OCSF mapping quality across the major Tier 2 vendor integrations (CrowdStrike, Okta, Palo Alto, Cisco, Zscaler) — the gap between marketing compliance claims and actual field-mapping completeness is the next evidence question. A managed multi-cloud OCSF equivalent (Azure Sentinel OCSF, GCP Chronicle OCSF, or a vendor-neutral platform) shipping at production quality. Production-validated AI-generated OCSF mapping for Tier 4 sources, which would meaningfully shrink the integration tail. Each of these moves the research-page anchor in a specific direction.
Useful, when its shape matches yours.
The full anchor hypothesis on OCSF, plus the contradiction tracking the petabyte-scale claim, are on the research page. The matrix offering applies these qualifications to the platform decision in your specific environment.