You enable access logging by turning on the load balancer’s access log delivery to an S3 bucket. Use a dedicated bucket with the right bucket policy and check that objects are being written for the correct load balancer and region. Review the logs for client IPs, target responses, TLS negotiation, and unusual request patterns.
How ELB access logging works in practice
For AWS Elastic Load Balancers, access logging is a delivery setting, not a separate analysis feature. Once enabled, the load balancer writes log files to an S3 bucket on a scheduled basis. The important operational detail is that the bucket must be dedicated or tightly controlled, because log delivery fails quietly when the bucket policy, region, or object path is wrong.
The logs are most useful when you treat them as evidence of request handling rather than just archival records. For application load balancers, classic load balancers, and network load balancers, the exact fields differ, but the purpose is the same: confirm who connected, how the load balancer negotiated the session, what target was selected, and whether the request pattern looks normal for the service.
That is why the first verification step is not “is logging enabled?” but “are objects arriving where I expect, with the expected prefix, for the correct load balancer and region?” If delivery is misconfigured, the control is present in the console but absent in the bucket, which is a common failure mode in multi-account and multi-region environments.
What to verify before you rely on the logs
The bucket policy must allow the ELB service to write objects, and the destination must match the AWS region where the load balancer exists. The bucket should be isolated from everyday application writes so that retention, lifecycle rules, and object ownership do not interfere with the logging stream.
Once delivery starts, validate that the files are readable and that they correspond to the expected traffic source. A good check is whether the filenames and prefixes clearly map to the load balancer and time window you intended. If you are using multiple load balancers, make sure you can distinguish them without relying on guesswork.
For readers who want a broader view of cloud audit evidence and retention patterns, NHIMG’s Cloud Logging and Audit Trail Guide is the best parent concept for treating ELB logs as part of a larger cloud audit trail.
It is also worth checking how the load balancer fits into the rest of the cloud identity and access path. When traffic is fronted by roles, temporary credentials, or other short-lived access paths, the logs become more valuable because they help distinguish legitimate automation from abuse. NHIMG’s Cloud Workload Identity Guide gives the surrounding control context for that kind of cloud access pattern.
What the logs can tell you, and what they cannot
ELB access logs are strongest for traffic reconstruction. They can help you review client IPs, target response behavior, TLS negotiation, and request bursts that do not fit the normal service profile. They are weaker as a complete investigation record because they do not replace application telemetry, WAF signals, or host-level logs.
Use them to answer practical questions: did the load balancer receive the request, did it forward it, how long did the backend take, and did TLS settings behave as expected? If a request was denied or malformed, the access log may still show the attempt, which is useful for baselining scanning and probing.
For abuse investigations, logs are most effective when paired with compromise response steps. If suspicious traffic suggests an exposed credential, misused session, or unusual automation path, NHIMG’s Cloud Credential Compromise Playbook provides the follow-on containment and investigation pattern that usually matters after access evidence appears.
When log review shows aggressive request patterns, failed handshakes, or odd backend targeting, it is worth comparing that signal with broader cloud abuse patterns rather than treating the ELB in isolation. NHIMG’s Edge Device Security Guide covers the adjacent operational reality that load balancers are internet-facing control points with logging and exposure implications.
Risk and Threat Considerations
Access logging is only useful if delivery is dependable and the bucket is protected. The main risk is false assurance: teams believe logging exists, but policy errors, region mismatches, or bucket misconfiguration leave gaps that attackers can exploit without leaving the expected trail.
Failure mechanism: The load balancer attempts delivery, but the S3 destination cannot accept or retain the files, so the investigation record is incomplete or absent when you need it most.
Impact: You lose visibility into request provenance, TLS behavior, and suspicious traffic patterns, which makes incident reconstruction slower and weakens detection of probing, abuse, and post-compromise activity.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-8 — Audit Log Management | ELB access logs are audit evidence that must be enabled, retained, and reviewed. |
| Recommendation — Centralise ELB log collection and routinely review delivered records for anomalies. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | This subject is about enabling and retaining request logs for security monitoring and analysis. |
| AU-9 — Protection of Audit Information | The S3 bucket and policy must protect logs from loss, tampering, or unauthorized access. | |
| AU-11 — Audit Record Retention | Access logs are only useful if retained long enough for investigation and review. | |
| Recommendation — Define which ELB events must be logged and verify the records are captured. Restrict write and read access to the log bucket and protect log integrity. Set retention and lifecycle rules that preserve ELB logs for investigation needs. | ||
| ISO/IEC 27001:2022 | A.8.15 — Logging | ELB access logging implements a technical logging control for cloud traffic visibility. |
| Recommendation — Enable and monitor ELB logging as part of your logging baseline. | ||
Practitioner Guidance
What to verify: Confirm that the bucket policy, region, prefix, and object ownership all line up with the exact load balancer you are instrumenting. A green console setting is not enough, evidence of delivered objects is what proves the control is working.
Common mistake: Treating access logs as a one-time setup item instead of an operating control. If the bucket lifecycle, permissions, or naming conventions change later, logging can silently degrade.
What good looks like: You can point to recent log objects, tie them to the correct load balancer, and use them to explain real client activity, TLS negotiation, and unusual request sequences without ambiguity.
Practitioner takeaway: ELB access logging is valuable only when you can prove delivery and retrieval, because the control exists to support investigation and verification, not just to satisfy a configuration checklist.