Service spotlight: querying years of audit history with CloudTrail Lake

The standard CloudTrail setup — trail to S3, Athena table on top, manual partition projection — works, but it’s a pipeline you own: someone has to get the Glue table schema right, keep partitions current, and remember it exists when an incident finally needs it at 2am. CloudTrail Lake exists to delete that pipeline.

What it actually is

CloudTrail Lake is a managed, queryable event store for CloudTrail data. You create an event data store, point it at management events, data events, or both, across one account or an entire AWS Organization, and AWS ingests, indexes, and retains that data for up to seven years without you touching S3 or Glue. Querying is plain SQL against the event data store through the CloudTrail console or the cloudtrail-data API — no Athena table definitions, no partition maintenance, no worrying that a schema drift in raw JSON broke your queries.

Under the hood it’s still built on the same event structure as classic CloudTrail-to-S3, so anything you already know about CloudTrail event fields (eventName, sourceIPAddress, userIdentity, requestParameters) transfers directly — the difference is entirely in ingestion and query ergonomics, not in what’s being captured.

Where it earns its keep

• Incident response and forensics. “Who called DeleteBucket in the last six months” is a SELECT with a WHERE clause instead of an Athena table setup exercise done under pressure during an active incident. That difference matters most exactly when you have the least patience for infrastructure work.
• Organization-wide queries. An event data store can aggregate events from every account in an AWS Organization into one queryable store, which is a real improvement over stitching together per-account S3 buckets and cross-account Athena access.
• Long retention without a lifecycle policy to babysit. Seven years of retention is configured once at store creation, not maintained via an S3 lifecycle rule someone has to remember not to break.
• Federated queries via generative AI tools. CloudTrail Lake events can be queried through Amazon Q and Bedrock Agents’ natural-language interfaces for teams that want “show me anomalous IAM activity this week” without writing SQL by hand — useful for on-call engineers who aren’t CloudTrail SQL experts.

Where it doesn’t replace the classic setup

CloudTrail Lake is not a replacement for a trail delivering to S3 if you need that data available to other tooling — a SIEM ingesting raw CloudTrail JSON from S3, a security data lake feeding a different query engine, or a compliance requirement for immutable S3 object storage with Object Lock. Lake’s event data store is queryable through its own API and console, not a general-purpose object store other systems can read from directly. Most mature setups run both: a trail to S3 for downstream tooling and archival, and an event data store for ad hoc SQL investigation.

The pricing model is the actual decision

CloudTrail Lake bills per GB ingested, with a choice between two pricing options at event-data-store creation: one-year extendable retention (higher ingestion price, retention extendable up to 7 years, data can be exported) or seven-year retention (lower ingestion price, fixed at 7 years, no export). That choice is set per store and isn’t something you casually change later, so decide upfront whether you’ll ever need to export the underlying data — if there’s any chance you will, pay for the extendable tier even though it costs more per GB, because re-ingesting historical data into a differently-configured store isn’t an option.

For accounts with high API call volume (a busy CI/CD pipeline hitting AWS APIs constantly, or verbose data events on S3/Lambda), ingestion costs can add up fast — model this against your actual CloudTrail event volume before turning on data events across every account in an Organization, rather than discovering the bill after the fact.

A practical tip

Start with management events only in the event data store, and add data events (S3 object-level, Lambda invocations) selectively for the handful of buckets or functions where object-level audit trail actually matters — data events are dramatically higher volume than management events, and are the single most common reason a CloudTrail Lake bill comes in far higher than expected.