A retailer's security team stores VPC flow logs, CloudTrail, and WAF logs in S3 across 25 accounts totaling terabytes per month. Analysts must run ad hoc SQL joins to trace an attacker IP across services for the past 90 days without moving data or provisioning servers. Which log analysis approach best meets scale and flexibility?
Select an answer to reveal the explanation.
Short Explanation
Terabytes in S3 call for querying where the data already sleeps. Athena lets you run serverless SQL across all those logs without hauling them anywhere.
Full Explanation
The correct approach is right because Amazon Athena queries S3 objects with SQL without servers to manage or data to reload, and partitioning by account, region, service, and date lets analysts prune terabytes to only relevant 90-day prefixes when joining VPC flow logs, CloudTrail, and WAF logs on attacker IP, which matches scale, ad hoc flexibility, and zero-move needs across 25 accounts. The OpenSearch approach fails by ingestion concept because it requires copying S3 data into indexed storage and operating domains, adding cost, duplication, and provisioning that the scenario forbids despite fast interactive search. The Redshift Spectrum approach fails by compute provisioning concept because external tables still need an available and tuned Redshift cluster or workgroup, breaking the without-provisioning-servers requirement even though it supports SQL joins in place. The Glue ETL to Parquet approach fails by movement concept because conversion rewrites and duplicates source logs into optimized datasets, violating without-moving-data and adding latency unsuitable for immediate tracing, even though Parquet improves later performance. For the exam, distinguish serverless in-place query from solutions that index, warehouse, or transform before query, as wording about moving data or provisioning is decisive. As a practical check, verify central S3 organization, Glue catalog partitions, and Athena workgroup limits before running the IP join over the 90-day window.