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?
answer
- free, on by default, nothing to enable
- a rolling ninety-day window
- control-plane calls only
- a trail is delivery, not recording
- opt-in data events, S3 lifecycle retention
basics
~20 sCloudTrail Event history is free, always on, and covers only the last 90 days of management events in the current region. A trail is the delivery configuration that writes events to an S3 bucket you own, giving you retention you control and the option to log data events.
solid answer
~40 sCloudTrail always records management-plane API calls, and the console's **Event history** exposes the last 90 days of them for the region you are looking at, free and with nothing to enable. Three things it will not do: go back further than 90 days, show data events such as S3 object-level `GetObject` or Lambda invocations, or feed anything downstream. A **trail** fixes all three — it continuously delivers events as gzipped JSON into an S3 bucket you own (optionally also into CloudWatch Logs), so retention becomes an S3 lifecycle decision rather than a fixed 90 days, and you can opt into data events and Insights events. What a trail does not buy you is speed: delivery is on the order of minutes, so anything that must react quickly should hang off EventBridge instead.
code
bash · 5 lines# Query the 90-day Event history directly - no trail required
aws cloudtrail lookup-events \
--lookup-attributes AttributeKey=EventName,AttributeValue=ConsoleLogin \
--max-results 10 \
--query 'Events[].{Time:EventTime,User:Username,Name:EventName}'go deeper
Be ready to say plainly that management events are recorded automatically and visible for 90 days, and that a trail is what you create to keep them longer or to send them to S3.
Explain the mechanics: what a trail delivers, where the objects land in the bucket, why data events are a separate opt-in, and why delivery takes minutes rather than seconds.
Show that you would have created the multi-region trail before the incident, and that you know which questions Event history can still answer during triage when no trail exists.
Own the standard: a management-event trail in every account as a baseline because the first copy is effectively free, with data events treated as a per-workload cost decision rather than a default.
## 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.
- How quickly does a trail deliver an event, and what would you use if you needed to react to an API call faster than that?Trail delivery to S3 is measured in minutes, because CloudTrail batches events into objects. For a fast reaction, match the call in EventBridge instead: management events arrive on the account's default bus with the detail type `AWS API Call via CloudTrail`, and a rule can invoke a Lambda function or an SNS topic directly. Use the trail as the durable record and EventBridge as the trigger.
- If someone deletes a trail, what happens to the log files it already delivered?Nothing — the objects already written stay in the S3 bucket, because they are ordinary S3 objects governed by your bucket's lifecycle and retention settings, not by CloudTrail. Deleting the trail only stops future delivery. Event history is likewise unaffected and keeps showing the last 90 days of management events.
- You have a multi-region trail. Where do IAM API calls appear?Globally-scoped services such as IAM and CloudFront record their events in us-east-1, whatever region you were calling from. A multi-region trail captures those global service events and delivers them to the same bucket, which is one of the practical reasons to create trails as multi-region rather than one per region.
saying these in an interview costs you the question
- Thinks CloudTrail keeps all history forever by default
- Expects S3 object GET calls in Event history
- Believes nothing is recorded until you create a trail
- Treats trail delivery as real-time, seconds not minutes
- Assumes one region's console view shows every region