AWS Load Balancer Support
ALB access logs: enable them and analyze with Athena.
ALB access logs show every request: the client, the target, status codes from both sides and the time spent in each stage. They are the quickest way to explain 5xx errors and slow endpoints. We set up logging, make it queryable and keep the cost down.
When You Need This
The situations where this work pays for itself.
Signs it is time
- You need to explain a spike in 502, 503 or 504 errors
- Some endpoints or targets are slow and CloudWatch averages hide it
- You want to find noisy clients, bots or abusive IPs
- You need an audit trail of requests to the load balancer
- Logs exist in S3 but nobody can query them
What you get
- Access logging enabled with a secured, lifecycle-managed bucket
- Athena table with partition projection
- A library of saved queries for errors, latency and clients
- Notes on how to read each log field
How we do it
A clear, safe process you can follow along with.
1. Enable access logs on the ALB
We set access_logs.s3.enabled and the bucket and prefix in load balancer attributes. The bucket policy must allow the ELB log delivery for the Region. Access logs support S3-managed encryption (SSE-S3), not SSE-KMS keys, so we plan the bucket accordingly.
2. Control retention and cost
We add an S3 lifecycle rule to transition or expire old logs. Access logs are compressed and delivered in batches, so volume depends on traffic, and we choose a retention that matches your audit needs.
3. Create an Athena table
We create a table with the ALB log format regular expression, and use partition projection on date so queries scan only the days requested instead of the whole bucket.
4. Query errors by source
We filter on elb_status_code and target_status_code to separate ELB-generated errors from application errors, then group by target IP and request URL to find the failing host or path.
5. Find slow requests
request_processing_time, target_processing_time and response_processing_time show where time goes. We list the top paths by high-percentile target_processing_time and compare across targets and deployments.
6. Find clients and abuse
We group by client IP, user agent and path to find bots, scrapers and bursts, and then feed findings into WAF rate-based rules or blocklists.
7. Save and share
We save the queries as named Athena queries or dashboards in your BI tool, and optionally alert on patterns using scheduled queries.
Mistakes we help you avoid
Common ways this goes wrong, and what we do instead.
Using a KMS key on the log bucket
Delivery fails because ALB access logs do not support SSE-KMS.
No partitioning in Athena
Every query scans the whole history and costs more.
Keeping logs forever by default
Storage grows quietly. Set lifecycle rules.
Logging sensitive data in URLs
Query strings appear in the logs, so we review what is placed in URLs.
Frequently Asked Questions
How do I enable ALB access logs?
Enable access logs in the load balancer attributes, choose an S3 bucket with a policy allowing log delivery, and optionally a prefix. Logs then arrive in the bucket in compressed files.
How do I query ALB logs?
Create an Athena table using the ALB log format, ideally with partition projection, then run SQL on fields such as elb_status_code, target_status_code and target_processing_time.
Are there other ALB logs?
ALB also offers connection logs for TLS and client connection details. Enable them where you need that visibility.
Want Help With ALB access logs: enable them and analyze with Athena?
Schedule an appointment. Tell us about your environment and we will outline the safest, highest-value approach.
Schedule Appointment › No commitment required