Across a large AWS estate the CloudTrail-related spend has become a material line on the bill, while compliance wants API activity kept for years. How do you decide what to log, where it lives, and for how long?

## Frame it as three separate decisions The reason CloudTrail spend sprawls is that teams treat it as one switch. It is really three decisions that should be made independently. **1. What is recorded.** Which categories, for which resources, in which accounts. **2. Where the durable copy lives, and for how long.** The system of record. **3. What hot surfaces exist on top.** Alerting and interactive query, which are separate products with separate meters. Conflating these produces the classic outcome: every event, in three places, forever. ## Decision one: what is recorded Management events are the floor and should never be the lever you pull. The first copy delivered per trail is free, the volume is small relative to application traffic, and the record is unrecoverable once the moment has passed — there is no way to reconstruct a control-plane change you did not capture. A baseline management-event trail everywhere is the cheapest insurance in AWS. Data events are where the money is, and they should be an application-level decision with a name attached. A useful policy is that a team enabling data events states which resource, which operations, and why. In practice most of the justified cases collapse to write activity on a specific bucket or prefix, which an advanced event selector expresses with `eventCategory`, `resources.type`, `resources.ARN` and `readOnly`. The overlooked cost is duplication. Two teams each creating a trail for the same activity pay twice for one stream; a platform-wide trail plus a per-account trail is a common way to end up billed twice for identical management events beyond the free copy. Consolidating delivery is often the single biggest saving available and costs no fidelity at all. ## Decision two: the durable copy and its retention Pick one place that is the answer to "where is the record". S3 is the usual choice: cheapest per byte, and everything else can read from it. Then set retention from the actual obligation. "Forever" is not a requirement, it is the absence of one — someone should be able to name the number of years and the rule behind it. Once named, encode it as an S3 lifecycle expiration rather than a habit. Archiving older objects to a colder storage class is the obvious next move, and it disappoints more often than people expect, for two reasons worth knowing: - **Object count, not byte count.** CloudTrail writes a great many small gzipped objects. Lifecycle transitions are charged per object, and colder classes carry per-object overhead and minimum storage durations. On millions of tiny objects the transition can consume much of the saving. Where volume is large, compacting the raw objects into bigger columnar files as part of an analytics pipeline saves far more than the storage class does. - **Retrieval turns minutes into hours.** Classes that require a restore before the data can be read make an investigation an ordeal: your query engine cannot read those objects until they are restored. If there is a realistic chance of needing the last year quickly, keep that window in a class that reads immediately and archive only the tail beyond it. ## Decision three: the hot surfaces Alerting and interactive query are separate products with separate meters, and each should be sized for its purpose rather than mirroring the archive. A CloudWatch Logs destination is for the recent window where metric filters and alarms live; keep its retention short, because you pay ingestion on everything you send there and the durable copy already exists in S3. An analysis surface — Athena over the bucket, or a managed event data store — is chosen on query economics: rare queries over large volume favour reading the S3 objects in place, frequent investigation favours paying at ingest to remove the setup. Neither should be treated as the archive. ## Verify, then act The discipline that separates a real answer from a plausible one is measurement. CloudTrail usage appears in Cost Explorer split by usage type, so you can see whether spend is data events, additional management-event copies, or Insights, before you change anything. Add the second-order costs that do not appear on the CloudTrail line at all — S3 storage growth on the trail bucket, CloudWatch Logs ingestion, ingestion into any event data store, and bytes scanned by queries. Teams routinely cut the visible line item and leave the larger downstream one untouched. ## What you refuse to trade A principal-level answer names the floor as well as the savings. I would not turn off management events, would not shorten retention below a stated obligation to hit a number, and would not archive the recent window into a class that cannot be read on demand. Everything above that floor — which data events, how many copies, how hot the query surface is — is negotiable and should be revisited when the workload changes.