AWS CloudTrail data events are off by default. Explain how they differ from management events, why switching them on account-wide can dominate the CloudTrail bill, and how you would scope them.

## Two categories, two orders of magnitude CloudTrail splits API activity into categories, and the split matters mostly because of volume. **Management events** are control-plane operations: creating, modifying, describing and deleting resources, plus sign-in and role-assumption activity. `ec2:RunInstances`, `s3:CreateBucket`, `iam:AttachRolePolicy`, `sts:AssumeRole`. Even a large estate produces a modest number of these per day, because they correspond to humans and pipelines changing infrastructure. **Data events** are data-plane operations against the contents of a resource: `s3:GetObject`, `s3:PutObject` and `s3:DeleteObject` on individual objects, `lambda:Invoke` on a function, item-level calls on a DynamoDB table. These correspond to *application traffic*. One moderately busy S3 bucket serving assets can generate more data events in an hour than the whole account generates management events in a month. **Insights events** are a third category: CloudTrail analyses management call volume and error rates and emits an event when the pattern deviates from the recent baseline. They are enabled separately and billed on the events analysed. ## Why the bill explodes The pricing shape follows the volume shape. As of 2025 the first copy of management events delivered per trail is free, and additional copies of the same management events are billed. Data events have no free allowance at all: you pay per event delivered, and then again for what those events cost downstream — S3 storage for the gzipped objects, CloudWatch Logs ingestion if you forward the trail there, ingestion charges if you feed them into CloudTrail Lake, and scanned bytes when something later queries them. That compounding is what turns a checkbox into a budget item. A team enables "all S3 data events" on all buckets during a security review, forwards the trail to CloudWatch Logs so alarms can be written on it, and discovers the following month that the CloudTrail and CloudWatch lines together are a material fraction of the account bill — driven almost entirely by read traffic nobody ever queries. ## Scoping is the whole skill CloudTrail gives you two generations of selector. **Basic event selectors** let you choose the read/write type (`ReadOnly`, `WriteOnly`, `All`) and list data resources by type and ARN, including S3 prefixes. **Advanced event selectors** are the richer form and are what you should reach for: they match on fields including `eventCategory`, `resources.type`, `resources.ARN`, `eventName`, `eventSource` and `readOnly`, with operators such as `Equals`, `NotEquals`, `StartsWith` and `NotStartsWith`. ```bash aws cloudtrail put-event-selectors --trail-name my-trail \ --advanced-event-selectors '[{ "Name": "Write-only object activity on one prefix", "FieldSelectors": [ {"Field": "eventCategory", "Equals": ["Data"]}, {"Field": "resources.type", "Equals": ["AWS::S3::Object"]}, {"Field": "readOnly", "Equals": ["false"]}, {"Field": "resources.ARN", "StartsWith": ["arn:aws:s3:::my-bucket/ingest/"]} ]}]' ``` The reasoning behind a scope like that is worth saying out loud in an interview: 1. **Reads usually outnumber writes by orders of magnitude**, and writes are the ones that change state. Filtering on `readOnly` false is often a 90%-plus volume cut on its own. 2. **Not every bucket deserves data events.** The bucket holding customer documents may; the bucket holding a public web front-end's static assets almost certainly does not. 3. **Prefixes narrow it further.** If only one path in a bucket is sensitive, match on the ARN prefix rather than the whole bucket. 4. **A second trail duplicating the same events doubles the bill.** If two teams each create a trail logging the same data events, you pay twice for one stream of activity. ## The trap of the opposite mistake The reflex after a cost review is to turn things off, and the wrong thing to turn off is management events. They are the cheap category — the first copy per trail is free — and they are the record you cannot reconstruct after the fact. The economically sound posture is management events everywhere as a baseline, and data events as a deliberate, narrow, per-resource decision that someone has justified. ## Verifying rather than guessing Don't assume which selector is driving the spend. CloudTrail usage appears in Cost Explorer split by usage type, so you can see whether the money is going to data events, extra management-event copies, or Insights. Pair that with the S3 storage growth on the trail bucket and the CloudWatch Logs ingestion figure, because the CloudTrail line item alone understates the true cost of a broad selector.