A fintech aggregates CloudTrail, VPC flow logs, and WAF logs in S3 but analysts struggle with different formats and slow Athena queries during triage. They need normalized fields and fast correlation dashboards. Which log normalization design provides correlated search for triage?

The correct design succeeds because Lambda parsing standardizes disparate CloudTrail, VPC flow, and WAF schemas into common normalized fields before indexing, while OpenSearch Service provides inverted-index search and near-real-time dashboards that enable fast pivoting and correlation during triage, directly resolving both format differences and slow Athena queries. The Glue crawler with partitioned Athena tables is a sound data lake pattern that improves structured SQL access, yet it fails the speed requirement because Athena remains scan-based without indexed correlated search, so triage stays slow. The Firehose to centralized S3 lake pattern is widely used for durable, cost-efficient retention and audit compliance, yet it fails the normalization requirement because it preserves raw formats without field-level standardization or correlation. The CloudWatch Logs with subscription filters and Logs Insights pattern is legitimate for centralized retention and ad-hoc investigation, yet it fails cross-source normalization because Insights queries separate log groups with distinct syntax rather than unified fields and purpose-built dashboards. Exam caveat: distinguish centralized storage from normalized correlated search, since many designs aggregate logs but do not normalize or accelerate investigation. Practical check: verify normalized fields like source IP, action, and result plus dashboard drill-down from one alert to related CloudTrail, flow, and WAF events within seconds.