AWS S3 access logs enable you to log individual object access patterns and related information such as object data actions, Service or Entity accessed the object, timestamp, protocol used, encryption algorithm etc. You can find more field information using this Link.

This information is helpful when we need to audit or troubleshoot any specific actions happened on the objects in a S3 bucket. Also, configuring access logs for important buckets which hold sensitive data is an AWS Best Practice. This has been recommended in most of Cloud Security Standards also.

Although it’s very helpful and easy to configure AWS S3 access logs, there are few points that you should consider when configuring the Access Logs.

Configuring access logs will incur cost as you will be putting log files for the access requests that comes to the target bucket. Higher the access requests are higher will be the number of log files.

When you configure the access logs for a bucket, do not configure the access log destination as the same bucket you want the access logs configured to. This will result in a cycle of access actions and will result in recursive access logging. Access logs take all object actions performed regardless of what the object is. When access logs are configured, this will also be set of objects put into the S3 bucket. If you put the access log destination as the same bucket you need the access logs to track object actions, it will create additional object actions for the logging objects. This will be costly and will create unnecessary number of logs compared to the actual object actions required. Also, this will result in increase of the storage size and the number of objects count of the bucket.

Also, this will be troublesome and increase cost when you need to query/analyze the logs as there are unnecessary logs created.

When configuring the Access Log Object Key format, use detailed method shown in the diagram below. This structure of the object path make it easy to partition in a cases like querying from AWS Athena for the investigations and analytics.

When storing the AWS Access Logs it’s better to use the AWS S3 event time as the source of date, as when analyzing or when doing an investigation, we’ll be using actual event times rather than the log delivery times. This will help to have a smooth and effective investigation/analysis and will help to cut down unnecessary time conversions that have to do when reporting or correlating data if we have used the log event time as the source of date.

Having AWS S3 access log enabled will increase the storage size and thus the cost. Also, by keeping unnecessary logs overtime makes its costly and harder to quickly find the information you need. So as a general rule of thumb, always cleanup what you don’t need.

Configuring the access logs should be based on the usage/requirement. Don’t just enable the access logs for each bucket just because the configuration is there or just because of a standard say it’s the best practice. Because for some buckets such as publicly accessible with general data, enabling access logs will be unnecessary. But if there are any S3 buckets with sensitive data is stored, enabling the access logs with be critical. So, in a nutshell you need to properly think, plan and should be able to validate your requirement for enabling the AWS S3 Access Logs to have an efficient and effective outcome from it.

Hope this article has helped you in your Cloud Journey. If you wish to read and learn in depth please follow the AWS Official Documentation here.