Use AWS CloudTrail when you need an audit trail of AWS API activity, including S3 bucket changes and selected object operations. Use Amazon S3 server access logging when you need detailed request records for a bucket, such as response codes, timing, or requests that failed authentication. The two overlap, but their event coverage and delivery guarantees differ.

AWS recommends CloudTrail for logging S3 bucket-level and object-level actions. For object activity, however, CloudTrail data events are not enabled by default. Server access logs can add useful request detail, but AWS delivers them on a best-effort basis, so they are not a complete accounting of every request.

Quick comparison

Question S3 server access logs CloudTrail
What is recorded? Detailed requests made to a bucket where logging is enabled, including object and bucket operations, request outcomes, and some lifecycle actions. Management events across AWS by default. S3 object operations are data events that you must select for a trail.
What detail is useful? Requester, source IP, operation, object key, HTTP status, error, bytes, and request timing. Some values can be unavailable. JSON event context such as event name, time, identity, source IP, and request parameters when the event provides them.
How soon do logs arrive? Best effort; most records arrive within a few hours, but records can be late, missing, or duplicated. Usually within minutes. AWS lists typical delivery around five minutes for data events and fifteen minutes for management events; actual timing is not guaranteed.
What is the format? Space-delimited text for direct delivery to an S3 bucket; structured JSON when delivered to CloudWatch Logs. JSON records, commonly delivered in compressed files to an S3 bucket.
What affects cost? Direct S3 delivery has no delivery charge; the log objects incur ordinary storage charges. CloudWatch Logs delivery has separate ingestion charges. For a trail, one copy of management events per account and Region delivered to S3 is free. Additional copies and data events incur CloudTrail charges; S3 storage and analysis can add costs.

For AWS's current comparison of S3 logging options, see Logging options for Amazon S3.

How their coverage differs

These tools answer related questions, but they do not collect the same events in the same way.

Log coverage

Server access logging is configured on a source bucket. It records request activity for that bucket, including object operations and bucket operations. Its records can include requests that fail authorization and requests that fail authentication, such as invalid credentials.

CloudTrail organizes events by type. Management events describe control-plane changes, such as changing a bucket policy; trails record management events by default unless configured otherwise. Data events describe resource operations, including reads and writes to S3 objects. Add selectors for the buckets, prefixes, and read or write activity you need. Data events can be high volume and incur charges. CloudTrail Event history shows only management events from the past 90 days in one Region; it does not show S3 object data events.

If selectors include the bucket where CloudTrail writes its own logs, those delivery writes can be logged as new S3 data events. Exclude that destination unless you need those records, or use CloudTrail's recursive logging control.

For the exact S3 event categories and setup choices, see AWS's Amazon S3 CloudTrail events documentation.

Fields, identity, and log format

Direct-to-S3 server access logs use space-delimited text records. Useful fields include the request time, apparent client IP, operation, object key, HTTP status, S3 error code, response bytes, and time spent handling the request. The requester field is not always an ARN: it can be a canonical user ID, an IAM user name and account, an assumed-role ARN, or a dash when the request was unauthenticated. A dash can also mean that a field is unavailable or does not apply.

CloudTrail uses JSON. Its records provide API event context such as the caller identity, event name, time, source IP, and request parameters when those fields apply. CloudTrail includes authorization failures such as AccessDenied, but does not deliver requests that fail authentication because the credentials are invalid. The S3 server access log format and CloudTrail event record reference describe field meanings and limits.

Do not assume S3 server access logs use a year/month/day folder layout by default. You can choose a simple prefix or date-partitioned object keys based on event time or delivery time. CloudTrail log paths include the account, event category, Region, and date.

When S3 server access logs are useful

Use server access logs when you need request-level operational evidence for a particular bucket: for example, to investigate response errors, understand request volume, or inspect request timing and transfer sizes.

Request and object activity

Server access logs show the operation, resource, outcome, and request details for activity against the configured bucket. They can help distinguish a burst of failed reads from successful downloads or identify which clients are generating traffic. They are bucket-scoped and do not provide the same identity context as CloudTrail.

Error and authentication troubleshooting

Use status and error fields to investigate patterns such as repeated AccessDenied or NoSuchKey responses. Server access logs also include requests that fail authentication, which CloudTrail does not deliver when the credentials are invalid. Neither log type explains the cause by itself; compare the request with the relevant IAM, bucket, endpoint, and encryption policies.

Presigned URL activity

Both server access logs and CloudTrail S3 data events can identify requests made with presigned URLs. In server logs, check the authentication type and request URI; in CloudTrail, check the authentication method and request parameters. A QueryString authentication value alone does not prove that a request used a presigned URL, so also look for X-Amz-Expires. The logs can show usage patterns, but they do not tell you who received or shared a URL. See AWS's guidance for identifying presigned requests.

When CloudTrail is useful

Account and resource changes

CloudTrail is the better starting point for investigating which AWS identity called an API, when it acted, and what service or resource was involved. Default management-event logging covers many administrative actions, such as changes to bucket policies and other AWS resources. A multi-Region trail can collect events from multiple AWS services and Regions.

S3 object events and multi-service activity

To audit S3 object reads or writes, explicitly select S3 data events for the required buckets or prefixes. The records can include event and identity context, but they are not copies of object contents and they do not appear in Event history. For a focused setup guide, see our guide to logging S3 activity with CloudTrail.

CloudTrail also helps investigate related API activity across services. It records events, not an ordered application trace, so use timestamps and request context to reconstruct a workflow rather than assuming the files form a precise sequence.

Audit and retention needs

CloudTrail supports log file integrity validation through digest files. This can help detect changes to delivered CloudTrail logs, but you must run the validation process and protect the log bucket and its policies. S3 server access logs do not provide the same integrity-validation feature. See AWS's CloudTrail log file integrity validation guide. Confirm that the events each system records match your audit requirement before treating either as evidence of complete activity.

Choose a logging approach

Start with the question you need to answer

  • For AWS-wide API history and identity context, use CloudTrail management events.
  • For S3 object-level API auditing, enable CloudTrail data events and scope them to the buckets, prefixes, and operations you need.
  • For request-level S3 troubleshooting, transfer details, or invalid-credential attempts, consider server access logging for the relevant bucket.

CloudTrail data events can be filtered by bucket or object prefix. Server access logs are enabled per bucket and do not offer the same object-prefix selector. Keep selectors and bucket settings aligned with the evidence you need.

When to use both

Use both when an investigation needs CloudTrail's AWS API context and S3's detailed request records. Make the purpose and coverage of each explicit: CloudTrail object data events must be selected, and server access log delivery can be delayed, incomplete, or duplicated. Neither should be treated as a real-time alert channel.

Costs and destination requirements

For direct S3 server access log delivery, AWS does not charge for delivery, but the objects use storage and may incur query or retrieval costs. CloudWatch Logs delivery uses separate ingestion pricing. For CloudTrail trails, one copy of management events per account and Region delivered to S3 is free; additional copies and all data events incur CloudTrail charges. S3 storage and analysis add their own costs. See AWS's CloudTrail trail cost guidance and check current pricing for your Region and event volume before enabling broad selectors.

Direct S3 server access log delivery has specific destination requirements: the target general purpose bucket must be in the same account and Region as the source bucket. It cannot have Requester Pays or S3 Object Lock enabled, or a default retention period. Use SSE-S3 for this destination; SSE-KMS default encryption can result in log objects you cannot read. With the default Bucket owner enforced Object Ownership, grant the logging.s3.amazonaws.com service principal permission to write through the destination bucket policy. ACL-based grants require ACLs to be enabled. S3 allows the source bucket to be its own target, but this creates an infinite logging loop; use a different bucket. See AWS's server access logging setup guide.

CloudTrail can write to a specified existing or dedicated S3 bucket; it does not require a separate bucket. Its bucket policy needs to let the cloudtrail.amazonaws.com service principal check the bucket and write under the trail's log prefix, scoped to the trail ARN with aws:SourceArn. If you choose SSE-KMS, use a key in the log bucket's Region and allow CloudTrail to encrypt and authorized readers to decrypt. See AWS's CloudTrail bucket policy guide. Our S3 access management guide explains how bucket policies and identity permissions work together.

Apply an S3 Lifecycle policy to log objects only after setting retention based on your operational and audit needs. Lifecycle expiration or transition changes how long logs remain readily available and can affect retrieval effort and cost.

Conclusion

Start with CloudTrail for API auditing, and add S3 server access logging where request-level diagnostics or invalid-credential attempts matter. Treat each source according to its actual event coverage and delivery behavior.

FAQs

When should I use S3 access logs and CloudTrail together?

Use both when an investigation needs CloudTrail identity and API context plus S3 request details, such as response timing or invalid-credential attempts. Enable CloudTrail data events for the objects in scope, and account for the best-effort delivery of server access logs.

What affects the cost of these logs?

Direct S3 server access log delivery has no delivery charge, but stored logs use S3 storage and querying them can add cost. CloudTrail charges apply to S3 data events and additional copies of management events; one management-event copy per account and Region delivered to S3 by a trail is free. Limit data-event selectors to the buckets, prefixes, and operations you need, and set retention deliberately.

When should I use S3 access logs instead of CloudTrail for compliance?

Use server access logs as supporting evidence when you need S3-specific request fields or invalid-credential attempts. Their best-effort delivery is not a complete record, so do not rely on them alone when a requirement calls for comprehensive audit coverage. Use CloudTrail with the required management and data-event selectors, then verify that the selected events and retention meet the control you need to satisfy.