What S3 Access Logs Reveal About Your Data Lake That CloudWatch Hides

CloudWatch surfaces bucket-level metrics. S3 access logs tell you which tables are growing, which pipelines have stopped, and which roles are crossing boundaries. Most data teams use the former and ignore the latter. The difference matters more than most realize.

The bucket-level illusion

A CloudWatch graph showing steady S3 storage growth looks healthy. It could also mean one table is accumulating orphaned files while three pipelines have silently failed. Bucket-level aggregation hides the composition of your data lake,you see the total, never the breakdown.

This isn't a flaw in CloudWatch,it's a design choice. CloudWatch is optimized for fast, low-cost metric collection at the resource level. Data lake health monitoring requires a different layer: one that understands the internal structure of your S3 environment, not just its external measurements.

What's actually in your S3 access logs

S3 server access logs record every request made against your buckets: requester ARN, operation type, object key, response size, HTTP status, processing time, and timestamp. This is request-level telemetry for your entire data lake,all the context you need to understand access patterns, pipeline behavior, and IAM activity.

• Every read request by Athena, Spark, or Glue,with the requester identity
• Every write by your ETL pipelines,with timestamps that reveal cadence
• Every metadata read against _delta_log/ or metadata/ prefixes,revealing table health overhead
• Every request from a browser or CLI session that hit your buckets,revealing human access patterns

Five things CloudWatch can't tell you that S3 logs can

1. Which tables have stopped receiving writes

CloudWatch shows you total requests across a bucket. S3 access logs show you the last write timestamp per prefix. A pipeline that stopped writing 12 days ago is invisible in CloudWatch but obvious in access log analysis.

2. Which IAM roles are accessing what

CloudWatch doesn't log requester identity. S3 access logs do. You can reconstruct a complete role-to-prefix access map from your logs,who's accessing what, with what SDK, at what frequency.

3. Which data lake tables have metadata bloat

High GET request rates to _delta_log/ or metadata/ prefixes relative to data reads indicate table metadata bloat,transaction logs or snapshot chains that are growing faster than they're being cleaned up. This is a performance and cost problem that CloudWatch can't surface.

4. Which Athena queries are scanning cold partitions

Athena scan metrics in CloudWatch are per-query aggregates. S3 access logs show you which specific partitions each Athena query touched,including partitions that haven't been modified in months but are still included in full table scans.

5. Which data should be in a cheaper storage class

CloudWatch shows storage volume by class. S3 access logs show last access time by object,revealing which specific prefixes and objects in STANDARD class haven't been touched in 90+ days and should be tiered to GLACIER or DEEP_ARCHIVE.

Making this operationally useful

The raw insight,S3 logs contain more signal than CloudWatch,is only useful if you can process that signal at scale. At petabyte volumes, S3 access logs generate hundreds of millions of lines per day. Parsing, correlating, and surfacing insights from that volume is the core engineering problem reCost solves.