Securing Your S3 Buckets with Powerful Monitoring Tools

If you need to monitor access to your Amazon S3 buckets, here’s how three AWS services work together: CloudTrail, S3 server access logs, and CloudWatch Logs. Each one gives you different visibility into what’s happening with your buckets.

What CloudTrail Does

CloudTrail records API calls made to S3. When someone creates a bucket, deletes one, or changes a policy, CloudTrail logs it. The logs show you what request was made, which IP address made it, who sent it, and when.

CloudTrail keeps 90 days of events in its Event history at no extra cost. For longer retention, you can set up a trail that delivers logs to an S3 bucket as compressed JSON files. From there, you can query them with Amazon Athena.

One thing CloudTrail doesn’t capture by default: individual object operations like GetObject or PutObject. For that, you need to enable S3 data events in your trail’s advanced event selectors.

- CloudTrail captures S3 API calls and stores them as events
- It logs the request type, source IP, who made it, and when
- A trail can deliver logs continuously to an S3 bucket
- Event history keeps 90 days of events free
- Data events (object-level operations) must be enabled separately

S3 Server Access Logs

These logs give you detailed information about requests to your bucket: request type, user agent, requester’s IP, and more. They’re useful for debugging and for spotting suspicious activity.

A few practical notes:

Cost: Log files land in S3 storage, and delivery is free. Regular S3 storage costs apply.

Don’t enable logging on the target bucket where logs are delivered. This creates an infinite loop of logs about logs.

Keep source and log buckets separate: Put logs in a different bucket than your source bucket. This makes log management cleaner and avoids billing confusion.

Use a prefix: Set a prefix like access-logs/ on your log objects so they’re easier to find.

AWS delivers logs on a best-effort basis. Most requests get logged within a few hours, but it’s not guaranteed. Your AWS billing reports might show requests that haven’t appeared in logs yet. Don’t rely on server access logs as your only record of bucket traffic.

CloudWatch Logs

CloudWatch Logs stores and monitors your bucket access logs. You can set up CloudWatch Request Metrics for S3 to track the number of requests in near-real time.

CloudWatch metrics also let you analyze request types and object sizes. This is useful for understanding your traffic patterns and spotting unusual activity.

One thing to keep in mind: CloudWatch metrics are a partial accounting of requests. They won’t match billing reports exactly, and delivery isn’t guaranteed. Use them alongside CloudTrail and server access logs for a complete picture.

Putting It Together

Each service covers different ground:

• CloudTrail: API-level events, who did what, audit compliance
• S3 Server Access Logs: Detailed request info, traffic patterns
• CloudWatch Logs: Centralized monitoring, metrics, alerting

Using all three together gives you the best visibility into bucket activity. CloudTrail handles the “who did what” questions, server access logs handle traffic analysis, and CloudWatch ties it together for monitoring and alerts.

For more on S3, check out these guides:

S3 Multi-Region Access Points

The Essential Guide to AWS Glacier

Amazon S3 Inventory

S3 Bucket Versioning: What It Is and Why You Need It