S3 access logs record every request made to a bucket: who made it, from where, which object it touched, what the result was and how long it took. They are indispensable for security investigations, troubleshooting, chargeback and compliance. At scale they are also a dataset in their own right. A cluster serving a few thousand requests per second produces hundreds of millions of log records a day, and handling them carelessly can slow the cluster, fill capacity and expose information that was meant to stay internal.
S3 access logging at scale is therefore a design question rather than a checkbox. It means deciding what to capture, where to send it, how long to keep it and who can read it, in a way that delivers the evidence teams need without turning logging into a second storage workload that competes with the first.
An S3 server access log entry typically includes:
Each record is small, a few hundred bytes. The volume comes from the request rate. At 5,000 requests per second, a cluster produces around 430 million records a day, which at roughly 300 bytes each is on the order of 130 GB of raw log data per day before compression.
Logging affects the cluster in three places: generating records on the request path, writing them somewhere, and reading them back for analysis. The table shows the usual options for the second step and their trade-offs.
| Log destination | Effect on the storage cluster | Strengths | Watch for |
|---|---|---|---|
| A log bucket in the same cluster | Adds writes and capacity on the cluster being logged | Simple, uses familiar S3 tooling | Logs of the log bucket, small-object overhead, capacity growth |
| A separate log cluster or bucket on other storage | Moves write and capacity load elsewhere | Isolates logs from production load and from production administrators | Network transfer, a second system to operate |
| Streaming to a log platform or SIEM | Minimal capacity impact on the cluster | Near-real-time search and alerting | Ingest cost, platform retention limits, data leaving the environment |
| Local files rotated off nodes | Uses node disk space briefly | Low overhead, flexible downstream processing | Loss if a node fails before rotation, collection pipeline reliability |
Writing logs to a bucket in the same cluster as individual small objects is the option most likely to cause trouble at scale, because it adds a stream of small writes and a growing object count. The overhead patterns described in the post on small object storage apply directly. Batching records into larger files before they are stored avoids most of it.
Not every bucket needs every request logged forever. A tiered approach keeps volume proportional to value:
The decision should be written down per bucket or per class of data, so that a later investigation does not discover that the one bucket that mattered was not logged.
Access logs are evidence. If an attacker can delete or alter them, their value in an investigation disappears. Logs that support security or compliance should be written somewhere production administrators cannot easily modify, and protected with retention locks for the period the organization needs. That period is usually set by policy or regulation, and it is often longer than the operational need. Retention of log data should be handled with the same care as other retained data, including the lifecycle rules that eventually remove it.
Logs also contain sensitive information of their own. Object keys can reveal customer names or project titles, and source IPs and identities are personal data in many jurisdictions. Where logs leave the environment, for example to an external analytics platform, that transfer belongs in the same analysis as other telemetry that crosses data boundaries.
Hundreds of millions of records a day are only useful if they can be queried. Common practices include converting logs into a columnar format partitioned by date and bucket, building summary tables for routine questions such as top requesters and error rates, and keeping raw logs for the detail an investigation needs. Request identifiers should be preserved end to end, so a client-side error can be traced to the matching server-side record. The same data then supports monitoring, chargeback and security review rather than three separate collection pipelines.
Scality RING exposes an S3 interface and emits operational metrics and logs that the operator keeps locally, which means request logs can remain inside the organization's own environment and be routed to whichever analysis and retention systems it chooses. RING is multi-tenant, with accounts, buckets and policy-based isolation, so log data can be kept in separate accounts and buckets that production users cannot reach.
Because RING runs on standard servers chosen by the customer, a separate logging tier can be sized for the request rate and retention period the organization actually needs, rather than sharing resources with the production workload by default.
Planned this way, access logging gives security, operations and finance teams the evidence they need, without becoming the busiest and least governed workload on the cluster.