All posts

Storage · 6 min read

Does your AWS setup need S3 server access logging?

Published 2026-09-09 · by the Plexavo team

Quick answer

S3 server access logging records every request made to a bucket, who made it, when, and what they did. It is genuinely useful for most setups, but there are real, legitimate cases where it is not worth enabling. Here is how to check your buckets, decide if you actually need it, and turn it on if you do.

How to check if it is already enabled

Run this for any bucket you want to check:

aws s3api get-bucket-logging --bucket YOUR-BUCKET-NAME

If the response is empty or has no LoggingEnabled key, logging is off for that bucket. To check every bucket in your account at once without writing a script, tools like Plexavo will do this automatically and flag any bucket where it is disabled.

Why it matters most of the time

If something goes wrong with a bucket, a leaked file, an unexpected access pattern, a question from a customer about who touched their data, server access logging is often the only record that exists. Without it, there is genuinely no way to reconstruct what happened after the fact, for a huge number of common setups.

This is easy to forget about precisely because it is boring. Nothing breaks when logging is off. The problem only shows up the one day you actually need the log and it is not there.

When it might genuinely not be worth it

There is a real, credible counterargument, and it is worth taking seriously rather than treating logging as something every bucket needs by default.

If a bucket is accessed only by a fixed, tightly controlled set of compute resources, for example hundreds or thousands of auto scaling nodes inside fully private subnets, with no public or broad internal access at all, server access logging can generate enormous volumes of log data for very little practical security value. At large scale, this has a real cost, and the audit value is much lower when access is already constrained by other controls like VPC endpoint policies and network isolation.

In that kind of setup, enabling logging on every bucket by default is not a sign of good practice, it is often just unnecessary overhead.

The part most guides leave out: CloudTrail data events

Server access logging is not the only way to get an audit trail for S3 activity. AWS CloudTrail can also be configured to record data events, which capture object level API calls (GetObject, PutObject, and similar) separately from server access logs.

If CloudTrail data events are already configured for a bucket, that bucket may already have meaningful audit coverage even with server access logging turned off. Any tool, including Plexavo today, that flags a bucket as having "no way to investigate after the fact" purely because server access logging is disabled is overstating the case unless it has also checked whether CloudTrail data events are covering that bucket. That is a real gap worth knowing about, since checking one setting in isolation can make a well covered bucket look worse than it actually is.

How to enable it, if you decide you need it

aws s3api put-bucket-logging \
  --bucket YOUR-BUCKET-NAME \
  --bucket-logging-status file://logging.json

Where logging.json specifies the target bucket for the logs and an optional prefix.

The honest summary

Enable server access logging by default unless you have a specific, deliberate reason not to, since for most buckets it is cheap and the alternative is having no record at all when you eventually need one. But if you are running at real scale with tightly controlled, private access already in place, it is fair to treat this as a genuine tradeoff rather than an automatic requirement, especially if CloudTrail data events already give you coverage.