S3 Access Logs: Why They Never Reach Your SIEM

Once enabled, S3 access logs record who read which object, but at terabyte scale, per-gigabyte SIEM ingestion makes full coverage a six-figure line item, so teams drop them. Here is why, and what it costs you.

Security teams do not skip S3 access logs because the reads are safe. They skip them because the logs are expensive to ingest. S3 server access logs at real scale run to terabytes a month, one line per request, and a SIEM prices ingestion by the gigabyte. At that volume, full coverage becomes a six-figure line item, so the logs get sampled, scoped to a handful of buckets, or dropped.

So the one source that records who read which object rarely reaches the tool built to catch a breach.

Security leaders we speak with describe the same trade: they accept the risk because no team can justify six figures to ingest logs it opens twice a year, during an incident.

Why the SIEM never sees S3 object reads

Most detection pipelines were built around control-plane events and network telemetry. S3 object reads are neither. They are high-volume data-plane events, and they behave badly at every stage of a traditional SIEM pipeline.

• Volume. A single analytics job can fan out into millions of GETs against one prefix in minutes. Normal traffic reads to a SIEM like a flood.
• Cost model mismatch. SIEM pricing rewards low-volume, high-signal sources. S3 read logs are high-volume and low-signal per line, so the economics push teams to drop the source.

The result is a source that is technically available, occasionally ingested, and almost never turned into a working detection.

What those logs are the only record of

S3 server access logs are off until you enable them. Once on, they record requests to your buckets, reads included. When an incident happens, that record is often the only evidence showing:

• Who accessed the object
• What was read or written
• When it happened

Delivered to an S3 bucket, server access logs are free to generate; you pay only S3 storage for the log objects. AWS delivers them on a best-effort basis, so their completeness and timing are not guaranteed (AWS documentation (opens in a new tab)). Where logging is on, the data exists. It never triggers an alert because it never reaches a query.

What the logs cannot tell you

When a new identity shows up reading your data, the log alone does not tell you a cause: it might be a new analyst, a misconfigured job, or something worth a page. The log records what happened, not intent.

FAQ

Why does my SIEM miss S3 object reads? The logs are usually dropped before ingestion. Per-gigabyte SIEM pricing makes terabytes of S3 read logs uneconomical, so the source is scoped down or never wired up. Where logging is on, it exists; it just never reaches a query.

Do S3 server access logs record who read an object? Yes, once logging is enabled. Each record shows who made the request, but delivery is best effort and not guaranteed to be complete (AWS documentation (opens in a new tab)).

Are S3 server access logs free? Delivered to an S3 bucket, they are free to generate. You pay only S3 storage for the log objects. The cost that stops teams is SIEM ingestion, not generation.

Does a new reader in the logs tell you the cause? No. The logs record what happened, not intent. Investigation is still a human step.

Takeaway

Once server access logging is on, the logs for your S3 reads exist. The reason your SIEM never sees them is a budget line, not a blind spot in the data.