ALB access logs missing: validate the logging bucket contract

A healthy load balancer can have an unhealthy logging path

Application traffic and access-log delivery are separate paths. An ALB may serve requests while its intended S3 log archive is absent or misconfigured. A dashboard showing healthy targets does not establish that request evidence is being retained where responders expect it.

This guide sets up and investigates ALB access-log delivery. It does not diagnose backend health checks or promise that access logs provide a transactional, complete record of every request. Define which operational and retention questions the archive is intended to answer.

Setup: review the destination before enabling logging

Record the ALB identity, Region, destination bucket, optional prefix and approved retention. The documented bucket requirements include placement in the load balancer's Region and the supported server-side encryption arrangement. Review the required delivery policy against the actual account and path.

An illustrative configuration worksheet is:

ALB ARN and Region:
S3 bucket, Region and log prefix:
Supported encryption configuration:
Delivery policy scope:
Retention and authorized readers:

The current ALB documentation specifies SSE-S3 for this logging destination. If an organizational policy requires another encryption arrangement, resolve that design conflict with the security owner rather than silently weakening a broad bucket policy. A dedicated approved logging destination may have different requirements from application data storage.

Illustrative incident: application-bucket policy is reused for logs

In this illustrative scenario, an operator chooses an existing application bucket whose policy and encryption requirements were designed for a different writer. The ALB's access logging cannot satisfy that destination contract even though the application itself uses the bucket successfully.

The team compares the load-balancer logging requirements with the selected bucket, policy and prefix. It creates or corrects the reviewed destination and validates new delivery. The example is fictional and does not imply that all existing buckets are unsuitable for logging.

Troubleshooting: test the writer's actual destination

Do not apply a policy intended for another load-balancer family without checking the ALB procedure. A successful S3 write by an administrator is also not a test of the service's delivery identity. Keep the service-writer and human-reader permissions separate.

Correct the destination and preserve privacy

Apply the narrow documented delivery permissions and approved encryption configuration. Limit readers to the teams that need request evidence, and choose lifecycle retention deliberately. Access logs can expose URLs and other request details that should not be broadly accessible.

Avoid public bucket access as a troubleshooting shortcut. If a bucket or prefix changes, document how investigators find the old and new records across the transition. Do not treat logging enablement as retroactive recovery of traffic that was never recorded in the selected archive.

Verification, alerting and SOP

Generate an approved test request and verify fresh log delivery after the service's normal delivery interval. Confirm the request can be associated with the correct load balancer and time window. Verify reader access, retention and the query procedure separately from bucket write eligibility.

An internal SLO can track log-delivery freshness for enrolled load balancers; an application SLA is a separate commitment. The SOP should record bucket contract, writer policy, prefix, retention, privacy handling, delivery checks, ownership and the fallback evidence available when the access-log path is impaired.

See Clouvenix observability monitoring for a reviewed implementation and operational handover.

Technical reference

AWS ALB access-log setup and bucket requirements. Reviewed 19 October 2026; use documentation for the installed product and release.