What AWS CloudTrail actually costs (2026)

CloudTrail is free until it is not, and the boundary is in a strange place: the second copy of your management events costs twenty times more per event than the S3 data events everyone assumes are the expensive part.

Is CloudTrail free?

The default is. From the AWS CloudTrail pricing page: "CloudTrail logs management events across AWS services by default and is available for no charge. You can view, search, and download the most recent 90-day history of your account's control plane activity at no additional cost using CloudTrail in the CloudTrail console."

On top of that, one delivered copy is free: "You can deliver one copy of your ongoing management events to your Amazon Simple Storage Service (S3) bucket for free by creating trails."

So a single organisation trail writing management events to S3 costs nothing for the events themselves. You still pay S3 for storing them, which is a separate meter and the one that grows.

Worth being precise about what "management events" covers, because the free copy applies to that category and nothing else. The CloudTrail concepts documentation separates management events, data events and network activity events, and only the first has a free delivery.

Does CloudTrail cost money once you go past the default?

Yes, on six meters. All of these are per-event or per-GB, all quoted from the pricing page:

Insights is priced separately again, "based on the number of management and data events analyzed per Insights type": $0.35 per 100,000 management events and $0.03 per 100,000 data events, per insight type. Enabling two insight types doubles it.

Why is a second trail so expensive?

Because management events are cheap once and expensive forever after. At $2.00 per 100,000 delivered, a second trail is twenty times the per-event rate of S3 data events, which is the opposite of most people's mental model.

This is the most common way an account acquires the charge, and it is almost always accidental. A landing zone creates an organisation trail. A team creates its own trail because it wants events in its own bucket. Both deliver, the first is free, the second is not, and nothing in either console mentions the other one exists.

The check is one call per account, and the field that matters is whether the trail includes management events at all:

aws cloudtrail describe-trails \
  --query 'trailList[].{Name:Name,Org:IsOrganizationTrail,MultiRegion:IsMultiRegionTrail,Bucket:S3BucketName}' \
  --output table

aws cloudtrail get-event-selectors --trail-name <name> \
  --query 'EventSelectors[].{Mgmt:IncludeManagementEvents,RW:ReadWriteType}'

Two trails both with IncludeManagementEvents: true means one of them is billing. If the second trail exists only to give a team read access to the events, a bucket policy on the first trail's bucket does the same job for nothing. The organization trail documentation covers the pattern that removes per-account trails entirely.

What makes data events expensive?

Volume, not rate. $0.10 per 100,000 is trivial per event and ruinous at S3 object scale, because a data event is generated per object operation. A bucket serving 50 million GET requests a month generates 50 million data events, which is $50, and a data lake doing ten times that is $500 a month to log reads nobody queries.

This is exactly the shape of workload we run: an Athena-backed lake where every query fans out into thousands of object reads. Logging data events on the CUR bucket produces a volume of events proportional to query activity rather than to anything security-relevant, which is a poor trade at any price.

Narrowing what you log is the first lever, and it is a configuration change rather than a trade-off: advanced event selectors filter data events by resource ARN prefix and by read or write type, so you can log writes on one bucket instead of everything on all of them.

Data event aggregation is the documented middle path. AWS describes it as consolidating "data events into 5-minute summaries, showing key trends like access frequency, error rates, and most-used actions", at $0.03 per 100,000 events analyzed. Read the footnote though: the charge is "In addition to data events charges." Aggregation is a readability feature, not a cheaper tier. It raises the bill.

What does sending events to CloudWatch Logs cost?

Two meters instead of one, and AWS says so directly: "Customers can enable CloudTrail management and data events to CloudWatch Logs without creating a trail. This incurs both CloudTrail event delivery charges and CloudWatch Logs ingestion fees."

So $0.25 per GB to CloudTrail, plus CloudWatch Logs ingestion on the same bytes, plus CloudWatch Logs storage for the retention period. That is three charges for one copy of one event. The same tiered Vended Logs meter is what makes VPC Flow Logs cost what they do, and the arithmetic is identical here.

It is worth doing when you need metric filters and alarms on control-plane activity, because S3 delivery cannot trigger anything. It is not worth doing as a general archive, which is what S3 delivery is already for.

When is CloudTrail Lake worth $0.75 per GB?

Lake is priced on ingestion, retention and the data scanned by queries, which makes it a managed analytics store rather than a log destination. Ingestion is $0.75 per GB for management, data and network activity events, and the pricing page offers "(1) one-year extendable retention pricing and (2) seven-year retention pricing."

The comparison that matters is against the thing you already have. Delivering to S3 and querying with Athena costs S3 storage plus Athena's per-TB scan charge, and gives you a table you control. Lake costs $0.75 per GB up front and gives you SQL without building anything. For an organisation already running a partitioned S3 lake with Athena over it, the second one is largely duplicate infrastructure. For one that is not, it removes a project.

One detail the pricing page volunteers, and it is a good one: "Queries performed by Amazon Athena on CloudTrail Lake data will be charged as Athena query pricing." The two are not mutually exclusive. And if you do point Athena at it, the per-query data scanned limit is the only control that actually cancels a runaway query.

How do you see it in your bill?

CloudTrail appears under its own service name, which makes it easier to isolate than most of the meters on this blog. Group by usage type to separate the six charges above, the same technique that resolves the EC2 - Other bucket:

aws ce get-cost-and-usage \
  --time-period Start=2026-07-01,End=2026-08-01 \
  --granularity MONTHLY \
  --metrics UnblendedCost UsageQuantity \
  --group-by Type=DIMENSION,Key=USAGE_TYPE \
  --filter '{"Dimensions":{"Key":"SERVICE","Values":["AWS CloudTrail"]}}'

A non-zero total on an account you believed was using only the free tier means a second trail somewhere. Note also that CloudTrail is not covered by Cost Optimization Hub, which generates no recommendations for it, so nothing will ever flag the duplicate for you.

Finally, the S3 side. Trail delivery writes objects continuously and forever unless a lifecycle rule says otherwise, and log objects are small, which runs straight into the 128 KB minimum billable size on Standard-IA. Transitioning a trail bucket to Standard-IA can cost more than leaving it in Standard. Expiration is the lever, not tiering.