Analysts need ad-hoc SQL over years of CloudTrail and app logs landed as Parquet on S3 without standing up a permanent warehouse cluster. Which approach fits?
Select an answer to reveal the explanation.
Short Explanation
The logs already live in the lake as Parquet. Point Athena at S3 and run SQL—no forever warehouse cluster to babysit.
Full Explanation
Ad-hoc SQL over years of CloudTrail and application logs landed as Parquet on S3 fits Amazon Athena: serverless interactive SQL against data in place without standing up a permanent data-warehouse cluster. Analysts register or discover the Parquet layout (often through the Glue Data Catalog), run the investigation queries they need for audits or incident review, and pay primarily for data scanned—ideal for intermittent municipal analytics rather than always-on clusters.
Loading every Parquet file into DynamoDB and Scanning for analytics abuses an OLTP key-value store for OLAP workloads and ignores columnar Parquet strengths. Installing a self-managed Hadoop cluster on one public EC2 instance permanently adds cost, patching, and attack surface the stem wants to avoid. Querying raw Parquet with API Gateway mapping templates alone is not a SQL engine and cannot replace Athena for analyst workflows.
Exam caveat: Athena cost and performance hinge on partitioning and file layout—partition by date or account and prefer columnar Parquet over giant JSON blobs when designing the log lake. Operational check: run a representative CloudTrail-oriented SQL statement in Athena against the Parquet prefix, review bytes scanned and runtime, and confirm the execution role can read only the intended log bucket paths.