Connection logs for your Application Load Balancer
Elastic Load Balancing provides connection logs that capture detailed information about requests sent to your load balancer. Each log contains information such as the client's IP address and port, listener port, the TLS cipher and protocol used, TLS handshake latency, connection status, and client certificate details. You can use these connection logs to analyze request patterns and troubleshoot issues.
Connection logs is an optional feature of Elastic Load Balancing that is disabled by default. After you enable connection logs for your load balancer, Elastic Load Balancing captures the logs and stores them in the Amazon S3 bucket that you specify, as compressed files. You can disable connection logs at any time.
You are charged storage costs for Amazon S3, but not charged for the bandwidth used by
Elastic Load Balancing to send log files to Amazon S3. For more information about storage costs, see Amazon S3 pricing
Contents
Connection log files
Elastic Load Balancing publishes a log file for each load balancer node every 5 minutes. Log delivery is eventually consistent. The load balancer can deliver multiple logs for the same period. This usually happens if the site has high traffic.
The file names of the connection logs use the following format:
bucket[/prefix]/AWSLogs/aws-account-id/elasticloadbalancing/region/yyyy/mm/dd/conn_log.aws-account-id_elasticloadbalancing_region_app.load-balancer-id_end-time_ip-address_random-string.log.gz- bucket
-
The name of the S3 bucket.
- prefix
-
(Optional) The prefix (logical hierarchy) for the bucket. The prefix that you specify must not include the string
AWSLogs. For more information, see Organizing objects using prefixes. AWSLogs-
We add the portion of the file name starting with
AWSLogsafter the bucket name and optional prefix that you specify. - aws-account-id
-
The Amazon account ID of the owner.
- region
-
The Region for your load balancer and S3 bucket.
- yyyy/mm/dd
-
The date that the log was delivered.
- load-balancer-id
-
The resource ID of the load balancer. If the resource ID contains any forward slashes (/), they are replaced with periods (.).
- end-time
-
The date and time that the logging interval ended. For example, an end time of 20140215T2340Z contains entries for requests made between 23:35 and 23:40 in UTC or Zulu time.
- ip-address
-
The IP address of the load balancer node that handled the request. For an internal load balancer, this is a private IP address.
- random-string
-
A system-generated random string.
The following is an example log file name with a prefix:
s3://my-bucket/my-prefix/AWSLogs/123456789012/elasticloadbalancing/us-west-2/2022/05/01/conn_log.123456789012_elasticloadbalancing_us-west-2_app.my-loadbalancer.1234567890abcdef_20220215T2340Z_172.160.001.192_20sg8hgm.log.gzThe following is an example log file name without a prefix:
s3://my-bucket/AWSLogs/123456789012/elasticloadbalancing/us-west-2/2022/05/01/conn_log.123456789012_elasticloadbalancing_us-west-2_app.my-loadbalancer.1234567890abcdef_20220215T2340Z_172.160.001.192_20sg8hgm.log.gzYou can store your log files in your bucket for as long as you want, but you can also define Amazon S3 lifecycle rules to archive or delete log files automatically. For more information, see Object lifecycle management in the Amazon Simple Storage Service User Guide.
Connection log entries
Each connection attempt has an entry in a connection log file. How client requests are sent is determined by the connection being persistent, or nonpersistent. Nonpersistent connections have a single request, which creates a single entry in the access log and connection log. Persistent connections have multiple requests, which creates multiple entries in the access log and a single entry in the connection log.
Contents
Syntax
Connection log entries use the following format:
[timestamp] [client_ip] [client_port] [listener_port] [tls_protocol] [tls_cipher] [tls_handshake_latency] [leaf_client_cert_subject] [leaf_client_cert_validity] [leaf_client_cert_serial_number] [tls_verify_status]The following table describes the fields of a connection log entry, in order. All fields are delimited by spaces. When new fields are introduced, they are added to the end of the log entry. You should ignore any fields at the end of the log entry that you were not expecting.
| Field | Description |
|---|---|
|
timestamp |
The time, in ISO 8601 format, when the load balancer successfully established or failed to establish a connection. |
|
client_ip |
The IP address of the requesting client. |
|
client_port |
The port of the requesting client. |
|
listener_port |
The port of the load balancer listener receiving the client request. |
|
tls_protocol |
[HTTPS listener] The SSL/TLS protocol used during handshakes. This field is set to |
|
tls_cipher |
[HTTPS listener] The SSL/TLS protocol used during handshakes. This field is set to |
|
tls_handshake_latency |
[HTTPS listener] The total time in seconds, with a millisecond precision, elapsed while establishing a successful handshake. This field is set to
|
|
leaf_client_cert_subject |
[HTTPS listener] The subject name of the leaf client certificate. This field is set to
|
|
leaf_client_cert_validity |
[HTTPS listener] The validity, with
|
|
leaf_client_cert_serial_number |
[HTTPS listener] The serial number of the leaf client certificate. This field is set to
|
|
tls_verify_status |
[HTTPS listener] The status of the connection request. This value is |
Error reason codes
If the load balancer is unable to establish a connection, the load balancer stores one of the following reason codes in the connection log.
| Code | Description |
|---|---|
|
|
The maximum client certificate chain depth has been exceeded |
|
|
The maximum client certificate size has been exceeded |
|
|
Client certificate has been revoked by the CA |
|
|
CRL processing error |
|
|
Client certificate is untrusted |
|
|
Client certificate is yet not valid |
|
|
Client certificate is expired |
|
|
Client certificate type is unsupported |
|
|
Client certificate is invalid |
|
|
Client certificate is rejected by custom server validation |
|
|
Unmapped runtime connection error |
Example log entries
The following are example connection log entries.
The following is an example log entry for a successful connection with a HTTPS listener with mutual TLS verify mode enabled on port 443:
2023-10-04T17:05:15.514108Z 203.0.113.1 36280 443 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 4.036 "CN=amazondomains.com,O=endEntity,L=Seattle,ST=Washington,C=US" NotBefore=2023-09-21T22:43:21Z;NotAfter=2026-06-17T22:43:21Z FEF257372D5C14D4 SuccessThe following is an example log entry for a failed connection with a HTTPS listener with mutual TLS verify mode enabled on port 443.:
2023-10-04T17:05:15.514108Z 203.0.113.1 36280 443 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 - "CN=amazondomains.com,O=endEntity,L=Seattle,ST=Washington,C=US" NotBefore=2023-09-21T22:43:21Z;NotAfter=2026-06-17T22:43:21Z FEF257372D5C14D4 Failed:ClientCertUntrustedProcessing connection log files
The connection log files are compressed. If you open the files using the Amazon S3 console, they are uncompressed and the information is displayed. If you download the files, you must uncompress them to view the information.
If there is a lot of demand on your website, your load balancer can generate log files with gigabytes of data. You might not be able to process such a large amount of data using line-by-line processing. Therefore, you might have to use analytical tools that provide parallel processing solutions. For example, you can use the following analytical tools to analyze and process connection logs:
-
Amazon Athena is an interactive query service that makes it easy to analyze data in Amazon S3 using standard SQL.