AWS CloudTrail shows recent API activity in the console under Event history without any setup. What does Event history actually cover, and what does creating a trail add?

## What is already on CloudTrail records management-plane API activity in every AWS account with nothing enabled. For each call it captures who made it (the IAM principal and, for assumed roles, the session), what was called (`eventSource` and `eventName`), when, from which source IP and user agent, the request parameters, and whether it failed and why. The console surfaces this as **Event history**, and the same data is reachable programmatically through the `LookupEvents` API. ```bash aws cloudtrail lookup-events \ --lookup-attributes AttributeKey=EventName,AttributeValue=TerminateInstances \ --max-results 5 ``` This costs nothing, and you cannot turn it off. ## The three limits of Event history **Ninety days, rolling.** As of 2025 the window is 90 days. Activity older than that is simply not there — no setting extends it, and if you had no trail configured at the time, the record is gone for good. This is the single fact that catches teams out: the first day anyone needs six-month-old activity is the day they discover nobody created a trail. **Management events only.** Management events are control-plane calls — `RunInstances`, `CreateBucket`, `AttachRolePolicy`, `AssumeRole`. Data events, the data-plane calls such as S3 object-level `GetObject`/`PutObject`, `lambda:Invoke`, and DynamoDB item-level operations, are off by default and never appear in Event history at all. Neither do Insights events. **One region at a time, and global services are special.** The console view is scoped to the region you are in, so a call made in eu-west-1 will not show up while you are looking at us-east-1. Globally-scoped services such as IAM and CloudFront record their events in us-east-1 regardless of where you were sitting when you made the call. Event history also only lets you look events up by a single attribute — an event name, a user name, a resource — not run an arbitrary aggregation across them. ## What a trail is A trail is a *delivery* configuration, not a switch that starts the recording. You point it at an S3 bucket you own and CloudTrail writes batches of events there as gzipped JSON objects, under a path shaped like: ``` AWSLogs/<account-id>/CloudTrail/<region>/YYYY/MM/DD/ ``` From that one change, several things follow: - **Retention becomes yours.** How long the record survives is now an S3 lifecycle decision, not a fixed 90 days. - **The data becomes queryable in bulk.** Objects in a bucket can be read by Athena, copied into CloudTrail Lake, or processed by anything else you like. - **Data events become available**, if you explicitly opt in and scope them — they are billed per event, so this is a deliberate choice rather than a default. - **CloudWatch Logs delivery becomes possible**, which is what you configure when you want metric filters and alarms over API activity. - **A multi-region trail** captures activity from every region into that single bucket, which is what makes "look everywhere" practical. ## What a trail does not add: latency A common misconception is that a trail makes CloudTrail real time. It does not. Events reach S3 in minutes rather than seconds, because CloudTrail batches them into objects. That is fine for investigation and for reporting, and unfit for anything that must respond immediately. When you need a fast reaction to an API call, the mechanism is Amazon EventBridge: management events are published to the account's default event bus with a detail type of `AWS API Call via CloudTrail`, and a rule can match on the event source and name and invoke a target directly. For object-level S3 activity, either enable S3's own EventBridge notifications or have a trail logging the relevant data events. ## The cost shape Event history is free. For a trail, the first copy of management events delivered per trail is free; a second trail recording the same management events is billed, as are data events (per event, with no free allowance) and the S3 storage and any CloudWatch Logs ingestion you add on top. That asymmetry is why the standard advice is to keep management events on everywhere and to treat data events as something you turn on deliberately, per resource. ## When Event history is enough For "which principal terminated that instance yesterday afternoon?", Event history answers in under a minute and needs nothing. As soon as the question spans more than 90 days, needs data-plane calls, or has to be answered by a machine rather than a human clicking, you need a trail — and you needed it *before* the event you are investigating.