The problem
I need to answer a straightforward question for licence management: how many GB per day does each CloudTrail eventName (e.g. Decrypt, GetSecretValue, AssumeRole) contribute to total ingestion? This is needed to make informed decisions about which event types to filter without unnecessarily dropping high-value detection signals.
What I have tried
1. Ingestion metrics data source (ingestion.* in dashboards)
ingestion.log_type = "AWS_CLOUDTRAIL"
match:
ingestion.log_type, ingestion.feed_id
outcome:
$total_bytes = sum(ingestion.log_volume)This returns total bytes per log_type and feed_id - useful for total volume, but the ingestion metrics schema has no product_event_type dimension. Byte volume cannot be broken down further by event name. Previous relevant post: Obtaining byte size by event type and ingestion labels | Community
2. UDM Search stats (metadata.product_event_type)
metadata.log_type = "AWS_CLOUDTRAIL"
match:
$event_type = metadata.product_event_type
outcome:
$count = count(metadata.product_log_id)
order:
$count descThis returns event count per product_event_type - useful for rank-ordering event types, but there is no byte-size field on the UDM event. ingestion.log_volume is not available in the UDM events data source.
How a competitor handles this
In Splunk this is a single query using the built-in _raw field, which carries the raw event string for every indexed event:
spl
sourcetype="aws:cloudtrail"
| stats sum(eval(len(_raw))) as total_bytes by eventName
| sort - total_bytesSplunk’s official CloudTrail licence optimisation guidance is built on exactly this capability. The reason it works is that _raw is a queryable field at search time, whereas in SecOps ingestion volume and UDM event content live in separate data sources that cannot be joined. Using ingest actions to filter AWS CloudTrail logs - Splunk Lantern
The ask
Is there a path I have missed to get byte volume broken down by metadata.product_event_type today or any workaround to get this? If not, this is a feature request to add product_event_type as a dimension to the ingestion metrics schema, or to expose raw log byte size as a field on the UDM event. For licence-managed environments ingesting high-volume log sources like CloudTrail, this is essential for making informed filtering decisions.

