Why aren't my Amazon S3 server access logs getting delivered?

4 minute read
0

I set up Amazon Simple Storage Service (Amazon S3) server access logging. However, the logs aren't populating the bucket that they're supposed to be delivered to.

Short description

If you set up Amazon 3 server access logging but you're not seeing logs in the expected bucket, then check for the following:

  • The Log Delivery group (delivery account) has access to the target bucket.
  • The bucket policy of the target bucket must not deny access to the logs.
  • Amazon S3 Object Lock must not be turned on for the target bucket.
  • If default encryption is turned on for the target bucket, AES256 (SSE-S3) must be selected as the encryption key.
  • Allow some time for recent logging configuration changes to take effect.

Resolution

The Log Delivery group has access to the target bucket

Server access logs are delivered to the target bucket (the bucket where logs are sent to) by a delivery account called the Log Delivery group. To receive server access logs, the Log Delivery group must have write access to the target bucket. Check the target bucket's access control list (ACL) to verify if the Log Delivery group has write access.

To check and modify the target bucket's ACL using the Amazon S3 console, do the following:

  1. Open the Amazon S3 console.
  2. From the list of buckets, choose the target bucket that server access logs are supposed to be sent to.
  3. Choose the Permissions tab.
  4. Choose Access Control List.
  5. Under S3 log delivery group, check if the group has access to Write objects. If the group doesn't have access to Write objects, proceed to the next step.
  6. Select Log Delivery.
  7. In the LogDelivery dialog box, under Access to the objects, select Write objects.
  8. Choose Save.

The bucket policy of the target bucket must not deny access to the logs

Check the bucket policy of the target bucket. Search the bucket policy for any statements that contain "Effect": "Deny". Then, verify that the deny statement isn't preventing access logs from being written to the bucket.

Note: It's a best practice to use a separate bucket for server access logs. By default, S3 buckets are private, so you don't need to use a deny statement in the bucket policy to prevent unauthorized access to the bucket. If an AWS Identity and Access Management (IAM) user or role is in the same AWS account as the bucket, and the IAM identity has permissions to the bucket in its IAM policies, then the user or role can access the bucket.

Amazon S3 Object Lock must not be turned on for the target bucket

Check if the target bucket has Object Lock turned on. Object Lock prevents server access logs from getting delivered, so you must turn off Object Lock on the bucket that you want logs sent to.

If default encryption is turned on for the target bucket, AES256 (SSE-S3) must be selected

If you use default encryption on the target bucket, then confirm that AES-256 (SSE-S3) is selected as the encryption key. Encryption using AWS-KMS (SSE-KMS) is not supported. For instructions on how to configure default encryption using the Amazon S3 console, see Turning on Amazon S3 default bucket encryption.

Allow some time for recent logging configuration changes to take effect

Turning on server access logging for the first time, or changing the target bucket for logs, can take time to fully implement. During the hour after you turn on logging, some requests might not be logged. During the hour after you change the target bucket, some logs might still be delivered to the previous target bucket. After you make a configuration change to logging, be sure to wait around one hour after the change to verify logs. For more information, see Best effort server log delivery.


Related information

How are logs delivered?

AWS OFFICIAL
AWS OFFICIALUpdated a year ago