Access Log Setup Fails with "Access Denied" on New S3 Bucket (Malaysia Region)

Question

Hi AWS team,

I'm currently trying to enable Access Logging for my Application Load Balancer in the Malaysia region (ap-southeast-5).

I followed the official AWS documentation and also referred to an Amazon Q suggestion for configuring the S3 bucket policy. However, when I try to enable access logging, I consistently receive the following error:

```
Access Denied for bucket: lbaccesslog1. Please check S3 bucket permission.
```

Here are the steps I’ve taken:

1. I created an S3 bucket named lbaccesslog1 in the same region.
2. I applied the recommended bucket policy from the AWS documentation for ALB access logging.
3. I ensured that the bucket is not blocking public access (though this shouldn't be required).
4. I am using the Malaysia region (ap-southeast-5), which was launched recently.

Despite these steps, I’m still facing the same "Access Denied" error.

Below is my S3 bucket policy

```
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "logdelivery.elasticloadbalancing.amazonaws.com"
      },
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::lbaccesslog1/AWSLogs/529088263660/*"
    }
  ]
}
```

Kiat · Answer

With the same configuration, I have no issues enabling access logs for the load balancer in the Singapore region. However, it does not work in the Malaysia region. I have reason to believe this is an issue on AWS's side. Please resolve this matter as soon as possible.

Kiat

answered a year ago

SAI MIN THU · Answer

Hi there,

When configuring ALB access logs, this is a common but annoying problem. Although it is evident that the ALB service lacks the required authorization to write to your bucket, determining the exact cause can be challenging. We should take extra care with the configuration since you're using the more recent Malaysia region (ap-southeast-5). Although your bucket policy is a good place to start, it probably lacks a necessary permission. Let's examine the most typical fixes.
Solution 1: The Full and Accurate Bucket Policy Only s3:PutObject is granted by your current policy. To list the bucket and confirm that it can write to it, the ALB service requires extra permissions. A more thorough policy is outlined in the official documentation.
Please update the Resource ARNs with your real AWS account ID and bucket name, replacing your entire bucket policy with the following.

#### Code #####
{
"Version" in json: "2012-10-17" 
"Statement": [ { "Effect": "Allow", "Principal": { "Service": "logdelivery.elasticloadbalancing.amazonaws.com" }, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::lbaccesslog1/AWSLogs/529088263660/*" }, { "Effect": "Allow", "Principal": { "Service": "logdelivery.elasticloadbalancing.amazonaws.com" }, "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::lbaccesslog1" } ]
 }

The second Statement block that grants s3:ListBucket on the bucket itself is the main change (notice that the Resource does not have a /* suffix). The missing component that frequently results in the "Access Denied" error is this permission. 
Solution 2: Confirm S3 Bucket Ownership Enforcements (essential for cross-accounting)
In 2023, S3 underwent a significant update pertaining to Bucket Owner Enforcement. This is a crucial check, but it is less likely to be the problem if your S3 bucket and ALB are in the same account. 
Open the console and navigate to your S3 bucket, lbaccesslog1. 
Select the Permissions tab. 
To access Object Ownership, scroll down. Select Edit. 
Make sure to select Bucket owner enforced and disable ACLs.
This is the safest and most advised configuration. The bucket policy you specified above serves as the only authority for access when this is enabled, and it ought to function properly.

Solution 3: Verify the ALB Configuration Again
Make sure you are entering the correct path when you enable access logs in the ALB console or CLI. Although not required, the prefix is advised for organization. 
Location of S3: lbaccesslog1 
AWSLogs/529088263660/alb or a comparable prefix is optional. 
The entire path will be built by the ALB as follows: s3://lbaccesslog1/[prefix]/elasticloadbalancing/...

Solution 4: Verify the Service Principal by Region 
Even though logdelivery.elasticloadbalancing.amazonaws.com is a global service principal, it's a good idea to check for a new region. In this sense, your policy is appropriate. This global principle is applied to all regions by the ELB service.
A Comprehensive Checklist to Address 
Use the Complete Policy: Make use of the PutObject and ListBucket permissions included in the policy from Solution 1 above. 
Verify Object Ownership: As mentioned in Solution 2, make sure that Bucket Owner Enforcement is enabled in your bucket. 
Turn off public access blocks: Even though you said you had already done this, it's still important to double check. "Block all public access" should be marked as Off in the "Permissions" tab of the S3 bucket under "Block public access."
Wait and Try Again: After making these adjustments, give the S3 permissions a few minutes to fully spread before attempting to enable access logs on your ALB once more. 
Why this was not working: To confirm that the bucket exists and has write access, the ALB service probably makes a ListBucket call first. This first check failed, resulting in the "Access Denied" error before a single byte could be written because your original policy only allowed PutObject.

In more than 99 percent of cases, the problem is fixed when the full policy and the appropriate object ownership setting are combined. Kindly follow these instructions and inform us if the issue continues.

Access Log Setup Fails with "Access Denied" on New S3 Bucket (Malaysia Region)

Code

Add your answer

Relevant content