CloudTrail management events — API calls that create, modify, or delete AWS resources — are logged for free by default and cost nothing extra to retain. Data events — object-level operations on S3 buckets, Lambda function invocations, DynamoDB item operations — are a different pricing tier entirely, and enabling them broadly ("log everything, just in case") on a high-traffic account can turn a near-zero-cost trail into a genuinely large monthly bill with very little warning until the invoice arrives.
Why Teams Turn This On Broadly, Then Regret It
Compliance frameworks and security guidance often say "log data events for sensitive data stores," which is correct advice interpreted too literally as "log every data event on every bucket and every function." For an S3 bucket receiving millions of GET requests a day, or a Lambda function invoked at high frequency, per-event data event logging costs scale directly with that traffic volume — and traffic volume is exactly the dimension most engineering teams don't think about when they enable a security feature.
Scoping Instead of Blanket Logging
CloudTrail supports scoping data events to specific resources rather than an account-wide "all S3 buckets" or "all Lambda functions" setting:
import boto3
cloudtrail = boto3.client("cloudtrail")
# Scope to specific high-sensitivity buckets only, not every bucket in the account
cloudtrail.put_event_selectors(
TrailName="organization-audit-trail",
AdvancedEventSelectors=[
{
"Name": "S3 data events - sensitive buckets only",
"FieldSelectors": [
{"Field": "eventCategory", "Equals": ["Data"]},
{"Field": "resources.type", "Equals": ["AWS::S3::Object"]},
{"Field": "resources.ARN", "StartsWith": [
"arn:aws:s3:::customer-pii-bucket/",
"arn:aws:s3:::financial-records-bucket/",
]},
],
}
],
)
This logs data events only for the buckets that actually warrant the audit trail's cost — customer PII, financial data, anything with a specific compliance requirement — rather than every bucket including build artifact caches, static asset buckets, and internal tooling storage that generate massive request volume with little audit value.
A Read/Write Split Worth Considering
Many compliance requirements care primarily about write and delete operations on sensitive data (who modified or deleted a record), not every read. Scoping data event selectors to write-only operations where read auditing genuinely isn't required can meaningfully reduce volume on read-heavy buckets without losing the evidence that actually matters for most SOC 2 or similar audit scenarios.
Estimating Cost Before Enabling Broadly
Before turning on data events for a new resource, estimate the request volume using S3 request metrics or Lambda invocation counts for the target resource, and multiply against the current per-event data event pricing to get a realistic monthly estimate — a five-minute exercise that avoids the far more common pattern of enabling broadly first and discovering the cost in next month's bill.
What This Doesn't Sacrifice
Scoping data events to specific resources doesn't reduce management event coverage at all — every IAM change, every security group modification, every resource creation and deletion continues to log at no additional cost, since that's the management event tier. The scoping decision only affects the expensive object-level and invocation-level data event tier, which is where the actual cost risk lives.
Frequently Asked Questions
Does scoping data events create a compliance gap?
Not if scoped correctly — the goal is matching data event coverage to what your specific compliance framework and risk assessment actually requires, not logging everything indiscriminately. A documented rationale for the scoping decision is itself good audit evidence.
How much can this typically save on a CloudTrail bill?
It depends heavily on account traffic patterns, but accounts that enabled broad data event logging on high-traffic S3 buckets or Lambda functions without realizing the cost implication often see the largest reductions once scoped to genuinely sensitive resources.
Can we scope data events per-account in an Organization trail?
Yes, organization trails support advanced event selectors that can differentiate by account, resource type, and specific resource ARN, giving fairly granular control across a multi-account structure.
Should CloudTrail data event scope be revisited over time?
Yes — as new sensitive data stores get created or old ones get decommissioned, the data event selector scope should be updated to match, ideally as part of a regular architecture or compliance review rather than a one-time setup.
See what an AWS cost audit finds in your CloudTrail configuration → rutagon.com/contact or call 907-841-8407.