Enable server access logging on the source S3 bucket and choose a target bucket to receive the logs. Make sure the target bucket permissions and lifecycle settings are appropriate, then validate that requests are being recorded. Review the logs for access patterns, unauthorised reads, and unexpected cross-account activity, while accounting for added storage and noise.
How S3 server access logging works
Server access logging is a bucket-level setting, not a separate service. You designate one S3 bucket as the source and a different bucket as the log destination, then S3 writes log objects that describe request activity against the source bucket. That makes the logging path itself part of your storage design, so the destination bucket must be reachable, writable, and managed like any other operational data store.
The practical detail that matters is that the logs are only useful if the destination can accept them consistently and retain them long enough for review. Cloud Logging and Audit Trail Guide is useful background when you want to treat the log bucket as an audit trail rather than a dumping ground, because retention, tamper resistance, and downstream analysis determine whether the records can support an investigation.
Because the source bucket can generate a lot of activity, logging also has an operational footprint. Expect extra storage, more objects to manage, and some noise from routine requests. The logging configuration should therefore match the purpose of the bucket: short-lived diagnostic logging for troubleshooting, or longer-lived audit logging for security review and accountability.
What to verify before you rely on the logs
Enabling logging is only the first step. You should confirm that the destination bucket policy allows S3 to deliver logs, that the bucket lifecycle rules fit your retention target, and that the target is not so tightly controlled that log delivery silently fails. A logging setup that cannot write or cannot retain records gives a false sense of visibility.
It is also worth checking whether the log destination is itself protected against accidental deletion, broad write access, or lifecycle rules that expire evidence too quickly. Cloud Misconfiguration Guide helps frame the usual failure modes: public exposure, overly broad permissions, and drift between intended and actual settings. Those same issues can undermine the log bucket even when the source bucket is configured correctly.
After enabling logging, generate a few test requests and verify that objects arrive in the target bucket. Then inspect the first log files for expected request types, source addresses, and timing patterns. If nothing appears, treat it as a configuration or permission problem before assuming there was no activity.
How to use S3 access logs for security review
Server access logs are most valuable when they are reviewed for patterns, not just archived. They can reveal unusual reads, repeated access to sensitive objects, request bursts from unexpected addresses, and cross-account activity that does not fit normal application behaviour. That makes them useful both for basic operational troubleshooting and for incident triage.
For deeper investigation, correlate S3 access logs with your broader cloud telemetry so you can distinguish legitimate application traffic from credential misuse or automation abuse. AWS Security Guide is a good companion when you want to pair bucket logging with CloudTrail, GuardDuty, and account hygiene so the logs become part of a wider detection and response pattern.
If the bucket stores sensitive data or supports business-critical workflows, logging should be one layer in a wider monitoring design rather than the only source of evidence. Access logs show who requested what and when, but they do not by themselves prove intent, data exfiltration, or successful abuse. They are most effective when you already know which accesses are normal and which ones need escalation.
Risk and Threat Considerations
S3 access logging can expose two classes of risk: visibility gaps if logging is misconfigured, and evidence loss if the destination bucket is too permissive, over-retained, or prematurely expired. The logging trail can also become noisy enough that real abuse is harder to spot unless you have a clear baseline for expected access.
Failure mechanism: Missing permissions, broken delivery paths, aggressive lifecycle expiry, or destination-bucket drift can prevent log creation or erase records before they are reviewed. An attacker or insider who can read or alter the log destination may also suppress or manipulate the audit trail.
Impact: You lose the ability to reconstruct access to the source bucket, weaken your incident response, and may miss cross-account access, unauthorised reads, or suspicious automation. In a breach scenario, that makes containment and forensics slower and less reliable.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-8 — Audit Log Management | S3 access logging is audit-log collection and retention. |
| Recommendation — Centralise and retain S3 access logs for review and investigation. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | Bucket access logging records events needed for accountability and review. |
| AU-9 — Protection of Audit Information | The destination log bucket must resist deletion, tampering, and premature expiry. | |
| Recommendation — Configure S3 to capture bucket access events and retain them for analysis. Protect the log bucket from alteration, deletion, and excessive retention loss. | ||
| ISO/IEC 27001:2022 | A.8.15 — Logging | ISO 27001 logging control applies to collecting and reviewing S3 access records. |
| A.8.16 — Monitoring activities | S3 logs support monitoring for abnormal reads and cross-account activity. | |
| Recommendation — Enable and review S3 access logging as part of operational monitoring. Use S3 access logs to monitor for suspicious access patterns. | ||
Practitioner Guidance
What to verify: Confirm that the source bucket can write to the chosen target bucket and that lifecycle rules preserve logs long enough for the review window you actually use. A quick UI toggle is not enough if the destination bucket policy or retention settings are incompatible with evidence collection.
Decision rule: If the bucket holds sensitive or regulated data, treat server access logging as mandatory operational evidence and pair it with alerting or periodic review. If the bucket is low-risk and high-volume, keep logging but tune retention and analysis so the signal remains usable.
Practitioner takeaway: The useful test is not whether logging is enabled, it is whether the resulting records are complete enough, durable enough, and interpretable enough to support a real investigation.