Issues with Access Logs on Network type of ALB: Seeking Solutions

There are a few issues with your current configuration that are likely causing the "Access Denied" error for your Network Load Balancer (NLB) access logs:

1. Principal Service: For NLB access logs, the correct principal service is "logdelivery.elb.amazonaws.com", not "delivery.logs.amazonaws.com" which is used for other AWS services.

2. Bucket Policy: The bucket policy for NLB access logs should be simpler than what you've provided. It should grant permissions to the Elastic Load Balancing service to write logs to your S3 bucket.

3. Encryption: While you're using SSE-S3 encryption, which is generally fine, for Network Load Balancer access logs specifically, if you want to use AWS KMS encryption (SSE-KMS), you must use customer managed keys.

Here's what you should do to resolve the issue:

1. Modify your S3 bucket policy to the following:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "logdelivery.elb.amazonaws.com"
},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::[your-bucket-name]/AWSLogs/[your-aws-account-id]/*",
"Condition": {
"StringEquals": {
"s3:x-amz-acl": "bucket-owner-full-control"
}
}
}
]
}

2. Ensure that your S3 bucket is in the same region as your Network Load Balancer.

3. Make sure the S3 bucket name doesn't include "AWSLogs" in its prefix.

4. When enabling access logs for your NLB, specify the correct S3 bucket name and prefix (if any) where you want the logs to be stored.

5. If you're still encountering issues, double-check that the Elastic Load Balancing service has the necessary permissions to write to your S3 bucket.

If you've followed these steps and are still experiencing issues, you may need to contact AWS support for further assistance, as there could be account-specific factors at play.
Sources
Enable access logs for your Network Load Balancer - Elastic Load Balancing
AwsElbLoadBalancerAccessLog - AWS Security Hub
AccessLog - Elastic Load Balancing

You are in the reigon which was available pre 2022 and has a different type of bucket policy. Heres the policy you need on the bucket

https://docs.aws.amazon.com/elasticloadbalancing/latest/application/enable-access-logging.html#attach-bucket-policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::797873946194:root"
      },
      "Action": "s3:PutObject",
      "Resource": "[destination-bucket]/*"
    }
  ]
}

Replace [destination-bucket] with your bucket. The account ID changes depending on which region your ALB is in. I have the account number in the policy for your region.

There are two kinds of modern load balancers that process traffic at the connection or request level:

1. Network Load Balancers (NLB)
2. Application Load Balancers (ALB)

You wrote that your load balancer is an ALB but also that the "type" field shows "Network" instead of "Application." That means it is not an ALB. It is an NLB.

NLBs primarily operate at the levels of the TCP and UDP protocols, with the option of performing TLS termination and re-encryption as an added layer on top of TCP connections.

The NLB won't process potential HTTP requests inside the traffic it forwards, and the connection doesn't even need to contain HTTP requests and responses. You can send anything TCP- or UDP-based through an NLB, such as raw database connections (PostgreSQL, MySQL, etc.), LDAP traffic to Active Directory or OpenLDAP servers, or any other TCP-, UDP- or TLS-based traffic. The NLB does have a logging option, but those logs only record TLS encryption details on traffic that the NLB decrypts, not HTTP request level information.

To record HTTP request details, you need to replace your load balancer with an ALB and enable request logging on it: https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-access-logs.html.

If you need static IP addresses for the load balancer, you can place an NLB in front of the ALB, so that all end user traffic arrives on the NLB and gets forwarded to the ALB for processing at the HTTP (and optionally TLS encryption) layer.

For more detailed logging, you can also associate a Web Application Firewall v2 web ACL with your ALB. It is able to collect all HTTP request headers and other detailed pieces of information, which aren't included in basic ALB access logs: https://docs.aws.amazon.com/waf/latest/developerguide/logging-fields.html

You cant have an AWS service principal in your own account. This is not valid. The service integration delivery.logs.amazonaws.com doesnt support this global condition key:

            "Principal": {
                "Service": "delivery.logs.amazonaws.com"
            },
            "Action": "s3:GetBucketAcl",
            "Resource": "arn:aws:s3:::[destination-bucket]",
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": ["My Account ID"]

Lets strip it right back. Try this one.

{
  "Version": "2012-10-17",
  "Statement": [
   {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::797873946194:root"
            },
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::[destination-bucket]/*"
        },
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "delivery.logs.amazonaws.com"
            },
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::[destination-bucket]/*",
            "Condition": {
                "StringEquals": {
                    "s3:x-amz-acl": "bucket-owner-full-control"
                }
            }
        },
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "delivery.logs.amazonaws.com"
            },
            "Action": "s3:GetBucketAcl",
            "Resource": "arn:aws:s3:::[destination-bucket]"
        }
  ]
}