# 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.

## Metadata

- **Canonical HTML**: https://ctrlb.ai/solutions/aws-cloudtrail
- **Section**: Solutions — AWS & CloudTrail

## At a glance

| Figure | What it refers to |
|--------|-------------------|
| 125 TB | Unique IP search in ~5 s |
| 1.3 PB/month | WAF and CloudTrail at Zepto |
| In place | Indexes land in your bucket |
| Data events | Affordable to keep on |

## What AWS logging costs you today

- CloudTrail data events are the most useful and the first thing disabled, because per-event SIEM pricing makes them unaffordable.
- Athena queries the same S3 objects but scans them, so a needle question takes five to ten minutes and bills by bytes scanned.
- VPC flow and WAF logs get sampled or dropped at exactly the volumes where an investigation needs them complete.
- The archive lifecycle rule that saves money is the one that makes last quarter unsearchable.

## What changes

- CtrlB indexes the Parquet already in your bucket — no new storage system and no copy of your AWS logs to keep in sync.
- A unique-IP search across 125 TB of CloudTrail returns in about five seconds, so an analyst follows a lead instead of batching questions.
- Data events, flow logs, and WAF stay on, because keeping them is a storage line item rather than a licensing negotiation.
- Every retained day answers at the same speed, so lifecycle policy and investigative reach stop being in tension.

## How it works

1. **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.
2. **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.
3. **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.

## Capabilities

- **CloudTrail at full fidelity**: Management and data events, unsampled, with years of retention at S3 pricing.
- **VPC flow logs**: High-volume network telemetry stays searchable rather than being sampled to fit a budget.
- **WAF and ALB**: Edge logs land schema-less, so an AWS-side field addition never becomes a mapping incident.
- **No data movement**: Objects stay in your account, your region, and your lifecycle rules.
- **Cross-account**: Central logging buckets fed by many accounts are one lake, not one lake per account.
- **Object Lock friendly**: Write-once objects with no compaction rewrites, so the audit trail stays intact.

## FAQ

**Do we have to change our CloudTrail configuration?**

No. If trails are already delivering to S3, CtrlB reads from that destination. The change is on the query side, not the collection side.

**How does this compare to Athena?**

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.

**Does it work with a central logging account?**

Yes. A central bucket fed by many accounts is the common case, and cross-account trails are indexed as one searchable history.

**What about GCS or Azure Blob?**

Both are supported. The architecture is object storage generally, not S3 specifically.

Markdown mirror: fetch `/solutions/aws-cloudtrail.md` for this page as plain Markdown.