6.3.2. Load Balancer and Service Access Logs
š” First Principle: Each layer of your application generates its own logs ā and problems at one layer look like problems at the next layer up. An ALB 502 error could be a misconfigured target, an overloaded instance, or an application crash. Service-specific access logs tell you which layer the failure originated at, preventing you from chasing symptoms rather than causes.
ELB Access Logs:
ALB and NLB can log every request to S3. ALB access log fields include:
- Timestamp, client IP, target IP, request details
- Response codes (both ALB's code and the target's code)
target_status_code: What the backend returnedelb_status_code: What the ALB returned to the client- Processing times (request processing, target processing, response processing)
- SSL handshake details
Common ALB Error Code Diagnoses:
| Error Code | Meaning | Likely Cause |
|---|---|---|
| 502 Bad Gateway | ALB received invalid response from target | Target app crashed, returned invalid HTTP, connection reset |
| 503 Service Unavailable | No healthy targets in target group | All targets failed health checks |
| 504 Gateway Timeout | Target didn't respond within timeout | App is slow or hung; increase target timeout? |
| 000 | Connection closed before response | Client disconnected (slow loris attack, network issue) |
WAF Logs and CloudFront Logs:
WAF logs show which rule blocked a request, the full request details, and the action taken (BLOCK, ALLOW, COUNT). Critical for tuning WAF rules ā a new managed rule group may block legitimate traffic that you need to identify and exclude.
CloudFront access logs (delivered to S3) include:
- Edge location that served the request
- Cache result (Hit, Miss, RefreshHit)
- Response bytes and time
- Viewer protocol and status code
Use CloudFront logs via Athena for querying ā the log format is TSV and Athena can query S3 directly with SQL for efficient analysis of large log volumes.
ā ļø Exam Trap: ELB access logs are not enabled by default ā you must explicitly enable them and specify an S3 bucket. The S3 bucket must be in the same region as the load balancer and have a bucket policy allowing the ELB delivery account to write logs. If you're asked why there are no access logs, the first check is whether logging was enabled on the load balancer.
Reflection Question: Users report intermittent 504 errors on your ALB. CloudWatch shows the ALB target group has healthy targets and normal request count. What log do you enable and what field do you examine to determine whether the issue is slow target response time or something else?
