CloudTrail Lake: bytes scanned are the query’s volume

The statistic is this query

A finished Lake query can report how many bytes it scanned. That number is the volume this statement read in this store. A small number can mean a narrow time bound. It does not mean the account has little history. A large number can mean a wide bound. It does not mean the account is under attack.

ResultsCount is how many rows came back. Bytes scanned is how much data was read to produce them. A query can scan a lot and return few rows, or scan little and return the rows that matched. Do not swap the two statistics.

The store is part of the number

The bytes belong to the event data store in the FROM clause. A different store, or a different time bound, is a different volume. Do not say one query was “cheaper” or “quieter” than another unless both notes show the store and the bounds.

If the statistic is missing, write “bytes scanned not in the result.” Do not estimate it from the row count.

What to file

File the query id, the store id, the time bounds, ResultsCount, and bytes scanned, each labeled. Do not file a sentence that calls the byte figure the size of the account or the number of API calls.

Worked case: a small scan called a quiet account

Query q-12 against the sandbox store, bounded to one hour, reports ResultsCount 2 and a small bytes-scanned figure. A draft says the account has almost no CloudTrail data. The store holds ninety days. The query never asked for them.

The note quotes the one-hour bounds, two rows, and the byte figure as this query’s volume. It says the account’s history was not measured. The ninety-day store is not described as empty.

query id: q-12
store: sandbox-mgmt
bounds: one hour
ResultsCount: 2
bytes scanned: this query's volume, as printed
account history: not measured
not: the account has almost no data