Skip to main content
emnode
Sign up
Compliance Medium severity

AWS Security Hub · ELB

ELB.5: Load balancers are not writing access logs

Written and reviewed by Emnode · Last reviewed

What does AWS Security Hub ELB.5 check?

ELB.5 fails when an Application or Classic Load Balancer does not have access logging enabled. Access logs capture the client IP, request line, latency, response code and user-agent for every request the load balancer handles.

Why does ELB.5 matter?

CloudTrail records the API calls an attacker made, but not the HTTP request that triggered them. Without access logs you cannot answer the questions an incident or a customer dispute hinges on: which IP, browser and path issued the request. The gap turns a routine forensic lookup into a stalled investigation, and the data is unrecoverable after the fact.

How do I fix ELB.5?

  1. Inventory load balancers and check the access_logs.s3.enabled attribute.
  2. Create an S3 bucket and attach the bucket policy that grants the regional ELB log-delivery account write access.
  3. Enable logging with modify-load-balancer-attributes pointing at the bucket and prefix, then confirm files start landing.
  4. Add an S3 lifecycle rule to expire old logs and keep storage costs flat; query with Athena when needed.

Remediation script · bash

# Load balancer: enable access logs to a dedicated, log-delivery-permissioned bucket.
aws elbv2 modify-load-balancer-attributes \
  --load-balancer-arn "$LB_ARN" \
  --attributes \
      Key=access_logs.s3.enabled,Value=true \
      Key=access_logs.s3.bucket,Value=acme-elb-logs-eu-west-1 \
      Key=access_logs.s3.prefix,Value=prod-api

# WAF web ACL: attach logging (Firehose/log-group name must start with aws-waf-logs-),
# redact credentials, and keep only blocked requests to cap volume.
aws wafv2 put-logging-configuration --logging-configuration \
  ResourceArn="$WEBACL_ARN",LogDestinationConfigs="arn:aws:firehose:us-east-1:111122223333:deliverystream/aws-waf-logs-prod",RedactedFields=[{SingleHeader={Name=authorization}}]

# Network Firewall: enable ALERT logs to CloudWatch and FLOW logs to S3.
aws network-firewall update-logging-configuration --firewall-name prod-egress-fw \
  --logging-configuration 'LogDestinationConfigs=[{LogType=ALERT,LogDestinationType=CloudWatchLogs,LogDestination={logGroup=/netfw/prod-egress-fw/alert}}]'

# Route 53: log group MUST be in us-east-1, then attach the query logging config.
aws logs create-log-group --log-group-name /aws/route53/customer-portal --region us-east-1
aws route53 create-query-logging-config --hosted-zone-id Z0J1K4M2X8N9A1 \
  --cloud-watch-logs-log-group-arn arn:aws:logs:us-east-1:123456789012:log-group:/aws/route53/customer-portal

Full walkthrough (console steps, edge cases and verification) in the lesson Enable network and edge logging (LB, WAF, firewall, DNS).

Is ELB.5 a false positive?

An internal-only load balancer fronting a low-value service (a dev sandbox, a health-check endpoint or an east-west service mesh hop) may deliberately run without access_logs.s3.enabled because the request volume would generate log noise and S3 cost with no forensic value, and the traffic is already captured upstream (VPC Flow Logs, a WAF, or the ingress ALB that does log). Because the control simply checks the boolean attribute, that intentional choice shows as a fail. Don't enable logging just to clear it: suppress the finding in Security Hub with a workflow status of SUPPRESSED and a note pointing to the upstream log source, or scope the FSBP standard so the resource is excluded, so the control stays meaningful for the internet-facing load balancers that genuinely need request logs.

Full lesson Enable network and edge logging (LB, WAF, firewall, DNS) Step-by-step remediation with CLI, code and persona-specific context.
AWS documentation for ELB controls ↗ Check your own account for ELB.5 →
Part of the learning path See what's happening

More ELB controls

  • ELB.1 ALB serves HTTP without redirecting to HTTPS
  • ELB.2 CLB SSL/HTTPS listeners should use ACM certs
  • ELB.3 CLB listeners should use HTTPS/TLS termination
  • ELB.4 ALB accepts malformed HTTP headers
  • ELB.6 Load balancers can be deleted by accident
  • ELB.7 CLBs should have connection draining
  • ELB.8 CLB SSL listeners should use strong policy
  • ELB.9 CLBs should have cross-zone balancing
  • ELB.10 CLBs should span multiple AZs
  • ELB.12 ALB desync mitigation mode
  • ELB.13 A single-AZ load balancer is a data-plane single point of failure
  • ELB.14 CLB desync mitigation mode