

# Access logs for your Classic Load Balancer
Access logs

Elastic Load Balancing provides access logs that capture detailed information about requests sent to your load balancer. Each log contains information such as the time the request was received, the client's IP address, latencies, request paths, and server responses. You can use these access logs to analyze traffic patterns and to troubleshoot issues.

Access logs are an optional feature of Elastic Load Balancing that is disabled by default. After you enable access logs for your load balancer, Elastic Load Balancing captures the logs and stores them in the Amazon S3 bucket that you specify. You can disable access logging at any time.

Each access log file is automatically encrypted using SSE-S3 before it is stored in your S3 bucket and decrypted when you access it. You do not need to take any action; the encryption and decryption is performed transparently. Each log file is encrypted with a unique key, which is itself encrypted with a KMS key that is regularly rotated. For more information, see [Protecting data using server-side encryption with Amazon S3-managed encryption keys (SSE-S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingServerSideEncryption.html) in the *Amazon S3 User Guide*.

There is no additional charge for access logs. You will be charged storage costs for Amazon S3, but will not be 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](https://aws.amazon.com/s3/pricing/).

**Topics**
+ [

## Access log files
](#access-log-file-format)
+ [

## Access log entries
](#access-log-entry-format)
+ [

## Processing access logs
](#log-processing-tools)
+ [Enable access logs](enable-access-logs.md)
+ [Disable access logs](disable-access-logs.md)

## Access log files


Elastic Load Balancing publishes a log file for each load balancer node at the interval you specify. You can specify a publishing interval of either 5 minutes or 60 minutes when you enable the access log for your load balancer. By default, Elastic Load Balancing publishes logs at a 60-minute interval. If the interval is set for 5 minutes, the logs are published at 1:05, 1:10, 1:15, and so on. The start of log delivery is delayed up to 5 minutes if the interval is set to 5 minutes, and up to 15 minutes if the interval is set to 60 minutes. You can modify the publishing interval at any time.

The load balancer can deliver multiple logs for the same period. This usually happens if the site has high traffic, multiple load balancer nodes, and a short log publishing interval.

The file names of the access logs use the following format:

```
amzn-s3-demo-loadbalancer-logs[/logging-prefix]/AWSLogs/aws-account-id/elasticloadbalancing/region/yyyy/mm/dd/aws-account-id_elasticloadbalancing_region_load-balancer-name_end-time_ip-address_random-string.log
```

*amzn-s3-demo-loadbalancer-logs*  
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](https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-prefixes.html).

`AWSLogs`  
We add the portion of the file name starting with `AWSLogs` after the bucket name and optional prefix that you specify.

*aws-account-id*  
The AWS 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-name*  
The name of the load balancer.

*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 if the publishing interval is 5 minutes.

*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 of "my-app":

```
s3://amzn-s3-demo-loadbalancer-logs/my-app/AWSLogs/123456789012/elasticloadbalancing/us-west-2/2018/02/15/123456789012_elasticloadbalancing_us-west-2_my-loadbalancer_20180215T2340Z_172.160.001.192_20sg8hgm.log
```

The following is an example log file name without a prefix:

```
s3://amzn-s3-demo-loadbalancer-logs/AWSLogs/123456789012/elasticloadbalancing/us-west-2/2018/02/15/123456789012_elasticloadbalancing_us-west-2_my-loadbalancer_20180215T2340Z_172.160.001.192_20sg8hgm.log
```

You 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](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html) in the *Amazon S3 User Guide*.

## Access log entries


Elastic Load Balancing logs requests sent to the load balancer, including requests that never made it to the back-end instances. For example, if a client sends a malformed request, or there are no healthy instances to respond, the requests are still logged.

**Important**  
Elastic Load Balancing logs requests on a best-effort basis. We recommend that you use access logs to understand the nature of the requests, not as a complete accounting of all requests.

### Syntax


Each log entry contains the details of a single request made to the load balancer. All fields in the log entry are delimited by spaces. Each entry in the log file has the following format:

```
timestamp elb client:port backend:port request_processing_time backend_processing_time response_processing_time elb_status_code backend_status_code received_bytes sent_bytes "request" "user_agent" ssl_cipher ssl_protocol
```

The following table describes the fields of an access log entry.


| Field | Description | 
| --- | --- | 
| time | The time when the load balancer received the request from the client, in ISO 8601 format. | 
| elb | The name of the load balancer | 
| client:port | The IP address and port of the requesting client. | 
| backend:port |  The IP address and port of the registered instance that processed this request. If the load balancer can't send the request to a registered instance, or if the instance closes the connection before a response can be sent, this value is set to `-`. This value can also be set to `-` if the registered instance does not respond before the idle timeout.  | 
| request\$1processing\$1time |  [HTTP listener] The total time elapsed, in seconds, from the time the load balancer received the request until the time it sent it to a registered instance. [TCP listener] The total time elapsed, in seconds, from the time the load balancer accepted a TCP/SSL connection from a client to the time the load balancer sends the first byte of data to a registered instance. This value is set to `-1` if the load balancer can't dispatch the request to a registered instance. This can happen if the registered instance closes the connection before the idle timeout or if the client sends a malformed request. Additionally, for TCP listeners, this can happen if the client establishes a connection with the load balancer but does not send any data. This value can also be set to `-1` if the registered instance does not respond before the idle timeout.  | 
| backend\$1processing\$1time |  [HTTP listener] The total time elapsed, in seconds, from the time the load balancer sent the request to a registered instance until the instance started to send the response headers. [TCP listener] The total time elapsed, in seconds, for the load balancer to successfully establish a connection to a registered instance. This value is set to `-1` if the load balancer can't dispatch the request to a registered instance. This can happen if the registered instance closes the connection before the idle timeout or if the client sends a malformed request. This value can also be set to `-1` if the registered instance does not respond before the idle timeout.  | 
| response\$1processing\$1time |  [HTTP listener] The total time elapsed (in seconds) from the time the load balancer received the response header from the registered instance until it started to send the response to the client. This includes both the queuing time at the load balancer and the connection acquisition time from the load balancer to the client. [TCP listener] The total time elapsed, in seconds, from the time the load balancer received the first byte from the registered instance until it started to send the response to the client. This value is set to `-1` if the load balancer can't dispatch the request to a registered instance. This can happen if the registered instance closes the connection before the idle timeout or if the client sends a malformed request. This value can also be set to `-1` if the registered instance does not respond before the idle timeout.  | 
| elb\$1status\$1code | [HTTP listener] The status code of the response from the load balancer. | 
| backend\$1status\$1code | [HTTP listener] The status code of the response from the registered instance. | 
| received\$1bytes |  The size of the request, in bytes, received from the client (requester). [HTTP listener] The value includes the request body but not the headers. [TCP listener] The value includes the request body and the headers.  | 
| sent\$1bytes |  The size of the response, in bytes, sent to the client (requester). [HTTP listener] The value includes the response body but not the headers. [TCP listener] The value includes the request body and the headers. | 
| request |  The request line from the client enclosed in double quotes and logged in the following format: HTTP Method \$1 Protocol://Host header:port \$1 Path \$1 HTTP version. The load balancer preserves the URL sent by the client, as is, when recording the request URI. It does not set the content type for the access log file. When you process this field, consider how the client sent the URL. [TCP listener] The URL is three dashes, each separated by a space, and ending with a space ("- - - ").  | 
| user\$1agent |  [HTTP/HTTPS listener] A User-Agent string that identifies the client that originated the request. The string consists of one or more product identifiers, product[/version]. If the string is longer than 8 KB, it is truncated.  | 
| ssl\$1cipher |  [HTTPS/SSL listener] The SSL cipher. This value is recorded only if the incoming SSL/TLS connection was established after a successful negotiation. Otherwise, the value is set to `-`.  | 
| ssl\$1protocol |  [HTTPS/SSL listener] The SSL protocol. This value is recorded only if the incoming SSL/TLS connection was established after a successful negotiation. Otherwise, the value is set to `-`.  | 

### Examples


**Example HTTP entry**  
The following is an example log entry for an HTTP listener (port 80 to port 80):

```
2015-05-13T23:39:43.945958Z my-loadbalancer 192.168.131.39:2817 10.0.0.1:80 0.000073 0.001048 0.000057 200 200 0 29 "GET http://www.example.com:80/ HTTP/1.1" "curl/7.38.0" - -
```

**Example HTTPS entry**  
The following is an example log entry for an HTTPS listener (port 443 to port 80):

```
2015-05-13T23:39:43.945958Z my-loadbalancer 192.168.131.39:2817 10.0.0.1:80 0.000086 0.001048 0.001337 200 200 0 57 "GET https://www.example.com:443/ HTTP/1.1" "curl/7.38.0" DHE-RSA-AES128-SHA TLSv1.2
```

**Example TCP entry**  
The following is an example log entry for an TCP listener (port 8080 to port 80):

```
2015-05-13T23:39:43.945958Z my-loadbalancer 192.168.131.39:2817 10.0.0.1:80 0.001069 0.000028 0.000041 - - 82 305 "- - - " "-" - -
```

**Example SSL entry**  
The following is an example log entry for an SSL listener (port 8443 to port 80):

```
2015-05-13T23:39:43.945958Z my-loadbalancer 192.168.131.39:2817 10.0.0.1:80 0.001065 0.000015 0.000023 - - 57 502 "- - - " "-" ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2
```

## Processing access logs


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 access logs:
+ Amazon Athena is an interactive query service that makes it easy to analyze data in Amazon S3 using standard SQL. For more information, see [Querying Classic Load Balancer logs](https://docs.aws.amazon.com/athena/latest/ug/elasticloadbalancer-classic-logs.html) in the *Amazon Athena User Guide*.
+ [Loggly](https://documentation.solarwinds.com/en/success_center/loggly/content/admin/s3-ingestion-auto.htm)
+ [Splunk](https://splunk.github.io/splunk-add-on-for-amazon-web-services/)
+ [Sumo Logic](https://www.sumologic.com/application/elb/)

# Enable access logs for your Classic Load Balancer
Enable access logs

To enable access logs for your load balancer, you must specify the name of the Amazon S3 bucket where the load balancer will store the logs. You must also attach a bucket policy to this bucket that grants Elastic Load Balancing permission to write to the bucket.

**Topics**
+ [

## Step 1: Create an S3 bucket
](#create-s3-bucket)
+ [

## Step 2: Attach a policy to your S3 bucket
](#attach-bucket-policy)
+ [

## Step 3: Configure access logs
](#configure-access-logs)
+ [

## Step 4: Verify bucket permissions
](#verify-access-logs)
+ [

## Troubleshooting
](#enable-access-logs-troubleshooting)

## Step 1: Create an S3 bucket


When you enable access logs, you must specify an S3 bucket for the access log files. The bucket must meet the following requirements.

**Requirements**
+ The bucket must be located in the same Region as the load balancer. The bucket and the load balancer can be owned by different accounts.
+ The only server-side encryption option that's supported is Amazon S3-managed keys (SSE-S3). For more information, see [Amazon S3-managed encryption keys (SSE-S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingServerSideEncryption.html).

**To create an S3 bucket using the Amazon S3 console**

1. Open the Amazon S3 console at [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/).

1. Choose **Create bucket**.

1. On the **Create bucket** page, do the following:

   1. For **Bucket name**, enter a name for your bucket. This name must be unique across all existing bucket names in Amazon S3. In some Regions, there might be additional restrictions on bucket names. For more information, see [Bucket quotas, limitations, and restrictions](https://docs.aws.amazon.com/AmazonS3/latest/userguide/BucketRestrictions.html) in the *Amazon S3 User Guide*.

   1. For **AWS Region**, select the Region where you created your load balancer.

   1. For **Default encryption**, choose **Amazon S3-managed keys (SSE-S3)**.

   1. Choose **Create bucket**.

## Step 2: Attach a policy to your S3 bucket


Your S3 bucket must have a bucket policy that grants Elastic Load Balancing permission to write the access logs to the bucket. Bucket policies are a collection of JSON statements written in the access policy language to define access permissions for your bucket. Each statement includes information about a single permission and contains a series of elements.

If you're using an existing bucket that already has an attached policy, you can add the statement for Elastic Load Balancing access logs to the policy. If you do so, we recommend that you evaluate the resulting set of permissions to ensure that they are appropriate for the users that need access to the bucket for access logs.

### Bucket policy


This policy grants permissions to the log delivery service.

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "logdelivery.elasticloadbalancing.amazonaws.com"
      },
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/prefix/AWSLogs/123456789012/*"
    }
  ]
}
```

For `Resource`, enter the ARN of the location for the access logs, using the format shown in the example policy. Always include the account ID of the account with the load balancer in the resource path of the S3 bucket ARN. This ensures that only load balancers from the specified account can write access logs to the S3 bucket.

The ARN that you specify depends on whether you plan to include a prefix when you enable access logs in [step 3](#enable-access-logs).

**Example S3 bucket ARN with a prefix**  
The S3 bucket name is amzn-s3-demo-logging-bucket and the prefix is logging-prefix.

```
arn:aws:s3:::amzn-s3-demo-logging-bucket/logging-prefix/AWSLogs/123456789012/*
```

[AWS GovCloud (US)] The following example uses the ARN syntax for the AWS GovCloud (US) Regions.

```
arn:aws-us-gov:s3:::amzn-s3-demo-logging-bucket/logging-prefix/AWSLogs/123456789012/*
```

**Example S3 bucket ARN with no prefix**  
The S3 bucket name is amzn-s3-demo-logging-bucket. There is no prefix portion in the S3 bucket ARN.

```
arn:aws:s3:::amzn-s3-demo-logging-bucket/AWSLogs/123456789012/*
```

[AWS GovCloud (US)] The following example uses the ARN syntax for the AWS GovCloud (US) Regions.

```
arn:aws-us-gov:s3:::amzn-s3-demo-logging-bucket/AWSLogs/123456789012/*
```

### Legacy bucket policy


Previously, for Regions available before August 2022, we required a policy that granted permissions to an Elastic Load Balancing account that was specific to the Region. This legacy policy is still supported, but we recommend that you replace it with the newer policy above. If you prefer to keep using the legacy bucket policy, which is not shown here, you can.

For reference, here are the IDs of the Elastic Load Balancing accounts to specify in `Principal`. Note that Regions that are not in this list never supported the legacy bucket policy.
+ US East (N. Virginia) – 127311923021
+ US East (Ohio) – 033677994240
+ US West (N. California) – 027434742980
+ US West (Oregon) – 797873946194
+ Africa (Cape Town) – 098369216593
+ Asia Pacific (Hong Kong) – 754344448648
+ Asia Pacific (Jakarta) – 589379963580
+ Asia Pacific (Mumbai) – 718504428378
+ Asia Pacific (Osaka) – 383597477331
+ Asia Pacific (Seoul) – 600734575887
+ Asia Pacific (Singapore) – 114774131450
+ Asia Pacific (Sydney) – 783225319266
+ Asia Pacific (Tokyo) – 582318560864
+ Canada (Central) – 985666609251
+ Europe (Frankfurt) – 054676820928
+ Europe (Ireland) – 156460612806
+ Europe (London) – 652711504416
+ Europe (Milan) – 635631232127
+ Europe (Paris) – 009996457667
+ Europe (Stockholm) – 897822967062
+ Middle East (Bahrain) – 076674570225
+ South America (São Paulo) – 507241528517
+ AWS GovCloud (US-East) – 190560391635
+ AWS GovCloud (US-West) – 048591011584

### Security best practices


To enhance security, use precise S3 bucket ARNs.
+ Use the full resource path, not just the S3 bucket ARN.
+ Include the account ID portion of the S3 bucket ARN.
+ Don't use wildcards (\$1) in the account ID portion of the S3 bucket ARN.

After you create your bucket policy, use an Amazon S3 interface, such as the Amazon S3 console or AWS CLI commands, to attach your bucket policy to your S3 bucket.

**To attach your bucket policy to your bucket using the console**

1. Open the Amazon S3 console at [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/).

1. Select the name of the bucket to open its details page.

1. Choose **Permissions** and then choose **Bucket policy**, **Edit**.

1. Update the bucket policy to grant the required permissions.

1. Choose **Save changes**.

**To attach your bucket policy to your S3 bucket using the AWS CLI**  
Use the [put-bucket-policy](https://docs.aws.amazon.com/cli/latest/reference/s3api/put-bucket-policy.html) command. In this example, the bucket policy was saved to the specified .json file.

```
aws s3api put-bucket-policy \
    --bucket amzn-s3-demo-bucket \
    --policy file://access-log-policy.json
```

## Step 3: Configure access logs


Use the following procedure to configure access logs to capture request information and deliver log files to your S3 bucket.

**Requirements**  
The bucket must meet the requirements described in [step 1](#create-s3-bucket), and you must attach a bucket policy as described in [step 2](#attach-bucket-policy). If you specify a prefix, it must not include the string "AWSLogs".

**To configure access logs for your load balancer using the console**

1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

1. On the navigation pane, under **Load Balancing**, choose **Load Balancers**.

1. Select the name of your load balancer to open its details page.

1. On the **Attributes** tab, choose **Edit**.

1. On the **Edit load balancer attributes** page, in the **Monitoring** section, do the following:

   1. Enable **Access logs**.

   1. For **S3 URI**, enter the S3 URI for your log files. The URI that you specify depends on whether you're using a prefix.
      + URI with a prefix: `s3://amzn-s3-demo-logging-bucket/logging-prefix`
      + URI without a prefix: `s3://amzn-s3-demo-logging-bucket`

   1. Keep **Logging interval** as `60 minutes - default`.

   1. Choose **Save changes**.

**To configure access logs for your load balancer using the AWS CLI**  
First, create a .json file that enables Elastic Load Balancing to capture and deliver logs every 60 minutes to the S3 bucket that you created for the logs:

```
{ 
  "AccessLog": {
    "Enabled": true,
    "S3BucketName": "amzn-s3-demo-logging-bucket",
    "EmitInterval": 60,
    "S3BucketPrefix": "my-app"
  }
}
```

Next, specify the .json file in the [modify-load-balancer-attributes](https://docs.aws.amazon.com/cli/latest/reference/elb/modify-load-balancer-attributes.html) command as follows:

```
aws elb modify-load-balancer-attributes --load-balancer-name my-loadbalancer --load-balancer-attributes file://my-json-file.json
```

The following is an example response.

```
{
    "LoadBalancerAttributes": {
        "AccessLog": {
            "Enabled": true,
            "EmitInterval": 60,
            "S3BucketName": "amzn-s3-demo-logging-bucket",
            "S3BucketPrefix": "my-app"
        }
    },
    "LoadBalancerName": "my-loadbalancer"
}
```

**To manage the S3 bucket for your access logs**  
Be sure to disable access logs before you delete the bucket that you configured for access logs. Otherwise, if there is a new bucket with the same name and the required bucket policy created in an AWS account that you don't own, Elastic Load Balancing could write the access logs for your load balancer to this new bucket.

## Step 4: Verify bucket permissions


After access logs are enabled for your load balancer, Elastic Load Balancing validates the S3 bucket and creates a test file to ensure that the bucket policy specifies the required permissions. You can use the S3 console to verify that the test file was created. The test file is not an actual access log file; it doesn't contain example records.

**To verify that Elastic Load Balancing created a test file in your S3 bucket**

1. Open the Amazon S3 console at [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/).

1. Select the name of the S3 bucket that you specified for access logs.

1. Navigate to the test file, `ELBAccessLogTestFile`. The location depends on whether you're using a prefix.
   + Location with a prefix: *amzn-s3-demo-loadbalancer-logs*/*logging-prefix*/AWSLogs/*123456789012*/ELBAccessLogTestFile
   + Location without a prefix: *amzn-s3-demo-loadbalancer-logs*/AWSLogs/*123456789012*/ELBAccessLogTestFile

## Troubleshooting


**Access Denied for bucket: *bucket-name*. Please check S3bucket permission**

If you receive this error, the following are possible causes:
+ The bucket policy does not grant Elastic Load Balancing permission to write access logs to the bucket. Verify that you are using the correct bucket policy for the Region. Verify that the resource ARN uses the same bucket name that you specified when you enabled access logs. Verify that the resource ARN does not include a prefix if you did not specify a prefix when you enabled access logs.
+ The bucket uses an unsupported server-side encryption option. The bucket must use Amazon S3-managed keys (SSE-S3).

# Disable access logs for your Classic Load Balancer
Disable access logs

You can disable access logs for your load balancer at any time. After you disable access logs, your access logs remain in your Amazon S3 until you delete the them. For more information, see [Working with S3 buckets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/creating-buckets-s3.html) in the *Amazon S3 User Guide*.

**To disable access logs for your load balancer using the console**

1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

1. On the navigation pane, under **Load Balancing**, choose **Load Balancers**.

1. Select the name of your load balancer to open its details page.

1. On the **Attributes** tab, choose **Edit**.

1. On the **Edit load balancer attributes** page, in the **Monitoring** section, disable **Access logs**.

**To disable access logs using the AWS CLI**  
Use the following [modify-load-balancer-attributes](https://docs.aws.amazon.com/cli/latest/reference/elb/modify-load-balancer-attributes.html) command to disable access logs:

```
aws elb modify-load-balancer-attributes --load-balancer-name my-loadbalancer --load-balancer-attributes "{\"AccessLog\":{\"Enabled\":false}}"
```

The following is an example response:

```
{
    "LoadBalancerName": "my-loadbalancer",
    "LoadBalancerAttributes": {
        "AccessLog": {
            "S3BucketName": "amzn-s3-demo-loadbalancer-logs",
            "EmitInterval": 60,
            "Enabled": false,
            "S3BucketPrefix": "my-app"
        }
    }
}
```