1.3 PB a month of security data, searched in seconds
Zepto searches WAF and CloudTrail logs directly on its own object storage. The data did not move and the bucket did not change — the query layer did.
The problem was never storage
Zepto’s WAF and CloudTrail logs were already landing in S3, which is where security data of that volume belongs. Keeping 1.3 PB a month was never the hard part; object storage is cheap and the retention was already there.
Searching it was the hard part. A query against the lake meant a full scan, and a full scan meant five to ten minutes of waiting per question. At that latency an investigation stops being a conversation with the data and becomes a queue: you batch the questions you can justify, and the ones you cannot justify go unasked.
What changed
CtrlB indexes the Parquet where it already lies. Compact inverted indexes are written into the same bucket as the data, so a needle query — one IP, one principal, one request id — reads an index and a handful of row groups instead of scanning a petabyte.
Those five-to-ten minute queries now return in roughly 500 ms to 5 seconds. Nothing about the data changed: same events, same files, same account, same region. Only the layer answering the question is different.
Same security agent. Same S3 data. Only the query layer changed.
What it unlocked
- Investigations run in one sitting instead of being batched into a queue of expensive questions.
- Retention is bounded by what object storage costs, not by what a hot tier can hold.
- The security agent and the analyst read the same evidence from the same files.
- No migration project: the data was already in S3, and it stayed there.
Run the same comparison on your bucket.
Point CtrlB at the Parquet you already have in S3 and time the same investigation both ways.