Your AWS logs are already in S3. Make them searchable.
CloudTrail, VPC flow, and WAF logs are the highest-volume, lowest-density data most teams own — expensive to keep in a SIEM and painfully slow to query with Athena. CtrlB indexes them where they already sit.
+
Index in place
The bucket you already have becomes the searchable lake
AWS is already writing Parquet to S3. CtrlB adds one prefix beside it — no second copy, no egress, and nothing leaves your account. The only thing that changes is how long a question takes.
s3://acme-logseu-west-1CloudTrailVPC FlowWAFCloudFrontYour AWS logs are already in S3. The query layer is what hurts.
CloudTrail, VPC flow, and WAF are the sources investigations need most — and the first ones teams sample away or leave unsearchable in the archive tier.
CloudTrailVPC flowWAFTypical Athena scan
125 TB
every object
CtrlB index lookup
12 MB
one row group
Cost per query
$142 → ¢
same SQL
SELECT * FROM cloudtrail WHERE sourceip = '203.0.113.44'
—
full table scan
—
index lookup
cloudtrail/vpcflow/waf/What AWS logging costs you today
What changes
CloudTrail data events are the most useful and the first thing disabled, because per-event SIEM pricing makes them unaffordable.
CtrlB indexes the Parquet already in your bucket — no new storage system and no copy of your AWS logs to keep in sync.
Athena queries the same S3 objects but scans them, so a needle question takes five to ten minutes and bills by bytes scanned.
A unique-IP search across 125 TB of CloudTrail returns in about five seconds, so an analyst follows a lead instead of batching questions.
VPC flow and WAF logs get sampled or dropped at exactly the volumes where an investigation needs them complete.
Data events, flow logs, and WAF stay on, because keeping them is a storage line item rather than a licensing negotiation.
The archive lifecycle rule that saves money is the one that makes last quarter unsearchable.
Every retained day answers at the same speed, so lifecycle policy and investigative reach stop being in tension.
How it works
If trails already deliver to S3, collection stays exactly as configured. CtrlB indexes where the data lands and answers with the SQL your team already writes.
indexes land in the same bucket · zero egress
Point at the bucket you have
CloudTrail, VPC flow, WAF, GuardDuty, and ALB logs are already landing in S3. CtrlB reads them where they are and writes its indexes into the same bucket.
targeted read · not a full-bucket scan
Index as events land
Compact inverted indexes are built at ingest, so a query for one principal, one IP, or one request id is a targeted read rather than a full-bucket scan.
SELECT eventtime, sourceip FROM cloudtrail WHERE sourceip = '203.0.113.44'
~8 min
0.0 s
Query with SQL you already write
The same SQL your team writes for Athena works here, against the same objects — only the latency and the scan bill change.
The sources that dominate your bill
Volume is what decides whether a source stays on. These are ordered by how much of it they produce — and the biggest three are the ones teams disable first.
CloudTrail
Management and data events, unsampled.
Data events stay onVPC Flow Logs
Every accepted and rejected flow, not a sample.
WAF
Edge allow/block decisions with the matched rule.
GuardDuty
Findings correlated against the raw evidence behind them.
ALB & CloudFront
Access logs at request granularity.
S3 access logs
Object-level reads and writes across buckets.
AWS Config
Resource configuration history as a searchable timeline.
CloudWatch export
Lambda, RDS, and ECS logs exported to S3.
What you get
CloudTrail at full fidelity
VPC flow logs
WAF and ALB
No data movement
Cross-account
Object Lock friendly
Same security agent. Same S3 data. Only the query layer changed.
View customer storyQuestions
No. If trails are already delivering to S3, CtrlB reads from that destination. The change is on the query side, not the collection side.
Athena is the right architecture — it queries data in place — but a needle query means a full scan. CtrlB adds inverted indexes beside the same Parquet, so point searches drop from minutes to sub-second and scan a fraction of the bytes.
Yes. A central bucket fed by many accounts is the common case, and cross-account trails are indexed as one searchable history.
Both are supported. The architecture is object storage generally, not S3 specifically.
Put it on your own bucket and see.
Point a source at CtrlB, keep everything else where it is, and compare the same investigation side by side.