

# Health check logs
<a name="load-balancer-health-check-logs"></a>

Elastic Load Balancing provides health check logs that capture detailed information about the health check status of your registered targets, including failure reasons when health checks fail. Health check logs are supported for EC2 instances, IP address, and Lambda function targets. Each log entry contains information such as the health check request type or connection, timestamp, target address, target group ID, health status and reason code. You can use these health check logs to analyze target health patterns, monitor health transitions, and troubleshoot issues.

Health check logs are an optional feature that is disabled by default. After you enable health check logs for your load balancer, Elastic Load Balancing captures the logs and stores them as compressed files in the Amazon S3 bucket that you specify. You can disable health check 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](https://aws.amazon.com/s3/pricing/).

**Topics**
+ [Health check log files](#health-check-log-file-format)
+ [Health check log entries](#health-check-log-entry-format)
+ [Example log entries](#health-check-log-file-entries)
+ [Configure log delivery notifications](#health-check-log-event-notifications)
+ [Processing health check log files](#health-check-log-processing-tools)
+ [Enable health check logs for your Application Load Balancer](enable-health-check-logging.md)
+ [Disable health check logs for your Application Load Balancer](disable-health-check-logging.md)

## Health check log files
<a name="health-check-log-file-format"></a>

Elastic Load Balancing publishes a log file for each load balancer node every 5 minutes. The load balancer can deliver multiple logs for the same period when a large number of targets are attached to the load balancer or a small health check interval is configured (for example, every 5 seconds).

The file names of the health check logs use the following format:

```
bucket[/prefix]/AWSLogs/aws-account-id/elasticloadbalancing/region/yyyy/mm/dd/health_check_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](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-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://amzn-s3-demo-logging-bucket/logging-prefix/AWSLogs/123456789012/elasticloadbalancing/us-east-2/2022/05/01/health_check_log_123456789012_elasticloadbalancing_us-east-2_app.my-loadbalancer.1234567890abcdef_20220215T2340Z_172.160.001.192_20sg8hgm.log.gz
```

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

```
s3://amzn-s3-demo-logging-bucket/AWSLogs/123456789012/elasticloadbalancing/us-east-2/2022/05/01/health_check_log_123456789012_elasticloadbalancing_us-east-2_app.my-loadbalancer.1234567890abcdef_20220215T2340Z_172.160.001.192_20sg8hgm.log.gz
```

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*.

## Health check log entries
<a name="health-check-log-entry-format"></a>

Elastic Load Balancing logs target health check results including the failure reasons for all registered targets of that load balancer. Each log entry contains the details of a single health check result made to the registered target.

**Topics**
+ [Syntax](#health-check-log-entry-syntax)
+ [Error reason codes](#health-check-error-reason-codes)

### Syntax
<a name="health-check-log-entry-syntax"></a>

The following table describes the fields of a health check log entry, in order. All fields are delimited by spaces. When we add a new field, we add it to the end of the log entry. As we prepare to release a new field, you might see an additional trailing "-" before the field is released. Ensure that you configure log parsing to stop after the last documented field, and update log parsing after we release a new field.


| Field (position) | Description | 
| --- | --- | 
|  type (1)  |  The type of health check request or connection. The possible values are as follows (ignore any other values): [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-health-check-logs.html)  | 
|  time (2)  |  Timestamp of when health check is initiated on a target, in ISO 8601 format.  | 
|  latency (3)  |  Total time elapsed (in seconds) to complete the current health check.  | 
|  target\$1addr (4)  |  IP address and port of the target in the format, IP:Port. Lambda’s ARN if the target is a Lambda function.  | 
|  target\$1group\$1id (5)  |  Name of the target group the target is associated with.  | 
|  status (6)  |  The status of the health check. This value is `PASS` if the health check succeeds. On an unsuccessful health check the value is `FAIL`  | 
|  status\$1code (7)  |  The response code received from the target for the health check request.  | 
|  reason\$1code (8)  |  The reason for failure if the health check fails. See [Error reason codes](#health-check-error-reason-codes)  | 

### Error reason codes
<a name="health-check-error-reason-codes"></a>

If the target health check fails, the load balancer will log one of the following reason codes in the health check log. 


| Code | Description | 
| --- | --- | 
|  `RequestTimedOut`  |  Health check request timed out while waiting for response  | 
|  `ConnectionTimedOut`  |  Health check failed because TCP connection attempt timed out  | 
|  `ConnectionReset`  |  Health check failed due to connection reset  | 
|  `ResponseCodeMismatch`  |  HTTP status code of the target’s response to the health check request did not match the configured status code  | 
|  `ResponseStringMismatch`  |  Response body returned by the target did not contain the string configured in the target group health check configuration  | 
|  `InternalError`  |  Internal load balancer error  | 
|  `TargetError`  |  Target returns 5xx error code in response to the health check request  | 
|  `GRPCStatusHeaderEmpty`  |  GRPC target response has a grpc-status header without value  | 
|  `GRPCUnexpectedStatus`  |  GRPC target responds with an unexpected grpc-status  | 

## Example log entries
<a name="health-check-log-file-entries"></a>

The following are examples of health check log entries. Note that the example text appears on multiple lines only to make them easier to read.

The following is an example log entry for a successful health check.

```
http 2025-10-31T12:44:59.875678Z 0.019584011 172.31.20.97:80 HCLogsTestIPs PASS 200 -
```

The following is an example log entry for a failed health check.

```
http 2025-10-31T12:44:58.901409Z 1.121980746 172.31.31.9:80 HCLogsTestIPs FAIL 502 TargetError
```

## Configure log delivery notifications
<a name="health-check-log-event-notifications"></a>

To receive notifications when Elastic Load Balancing delivers logs to your S3 bucket, use Amazon S3 Event Notifications. Elastic Load Balancing uses [PutObject](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObject.html), [CreateMultipartUpload](https://docs.aws.amazon.com/AmazonS3/latest/API/API_CreateMultipartUpload.html), and [POST Object](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectPOST.html) to deliver logs to Amazon S3. To ensure that you receive all log delivery notifications, include all of these object creation events in your configuration.

For more information, see [Amazon S3 Event Notifications](https://docs.aws.amazon.com/AmazonS3/latest/userguide/EventNotifications.html) in the *Amazon Simple Storage Service User Guide*.

## Processing health check log files
<a name="health-check-log-processing-tools"></a>

The health check log files are compressed. 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 health-check logs:
+ Amazon Athena is an interactive query service that makes it easy to analyze data in Amazon S3 using standard SQL.
+ [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 health check logs for your Application Load Balancer
<a name="enable-health-check-logging"></a>

When you enable health check logs for your load balancer, you must specify the name of the S3 bucket where the load balancer will store the logs. The bucket must have a bucket policy that grants Elastic Load Balancing permission to write to the bucket.

**Topics**
+ [Step 1: Create an S3 bucket](#health-check-log-create-bucket)
+ [Step 2: Attach a policy to your S3 bucket](#attach-bucket-policy-health-check)
+ [Step 3: Configure health check logs](#enable-health-check-logs)
+ [Step 4: Verify bucket permissions](#verify-bucket-permissions-health-check)
+ [Troubleshooting](#bucket-permissions-troubleshooting-health-check)

## Step 1: Create an S3 bucket
<a name="health-check-log-create-bucket"></a>

When you enable health-check logs, you must specify an S3 bucket for the health-check logs. You can use an existing bucket, or create a bucket specifically for health-check logs. 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 restrictions and limitations](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
<a name="attach-bucket-policy-health-check"></a>

Your S3 bucket must have a bucket policy that grants Elastic Load Balancing permission to write the health check 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 health check 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 health check logs.

### Bucket policy
<a name="bucket-policy-logdelivery-health-check"></a>

This policy grants permissions to the specified 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-logging.md#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
<a name="legacy-bucket-policy"></a>

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 policy, which is not shown here, you can.

 For reference, here are the IDs of the Elastic Load Balancing accounts to specify in `Principal` in the legacy policy. Note that Regions that are not in this list do not support the legacy 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

### Outposts Zones
<a name="bucket-policy-outposts"></a>

The following policy grants permissions to the specified log delivery service. Use this policy for load balancers in Outposts Zones.

```
{
    "Effect": "Allow",
    "Principal": {
        "Service": "logdelivery.elb.amazonaws.com"
    },
    "Action": "s3:PutObject",
    "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/prefix/AWSLogs/123456789012/*"
    "Condition": {
        "StringEquals": {
            "s3:x-amz-acl": "bucket-owner-full-control"
        }
    }
}
```

For `Resource`, enter the ARN of the location for the access logs. 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-logging.md#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/*
```

**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/*
```

### Security best practices
<a name="bucket-policy-security-best-practices"></a>

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.

------
#### [ Console ]

**To attach your bucket policy to 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 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**.

------
#### [ AWS CLI ]

**To attach your bucket policy to your S3 bucket**  
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 health check logs
<a name="enable-health-check-logs"></a>

Use the following procedure to configure health check logs to capture and deliver log files to your S3 bucket.

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

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

------
#### [ Console ]

**To enable health check logs**

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

1. In the navigation pane, choose **Load Balancers**.

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

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

1. For **Monitoring**, turn on **Health Check 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://bucket-name/prefix`
   + URI without a prefix: `s3://bucket-name`

1. Choose **Save changes**.

------
#### [ AWS CLI ]

**To enable health check logs**  
Use the [modify-load-balancer-attributes](https://docs.aws.amazon.com/cli/latest/reference/elbv2/modify-load-balancer-attributes.html) command with the related attributes.

```
aws elbv2 modify-load-balancer-attributes \
    --load-balancer-arn load-balancer-arn \
    --attributes \
        Key=health_check_logs.s3.enabled,Value=true \
        Key=health_check_logs.s3.bucket,Value=amzn-s3-demo-logging-bucket \
        Key=health_check_logs.s3.prefix,Value=logging-prefix
```

------
#### [ CloudFormation ]

**To enable health check logs**  
Update the [AWS::ElasticLoadBalancingV2::LoadBalancer](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-elasticloadbalancingv2-loadbalancer.html) resource to include the related attributes.

```
Resources:
  myLoadBalancer:
    Type: 'AWS::ElasticLoadBalancingV2::LoadBalancer'
    Properties:
      Name: my-alb
      Type: application
      Scheme: internal
      Subnets: 
        - !Ref subnet-AZ1
        - !Ref subnet-AZ2
      SecurityGroups: 
        - !Ref mySecurityGroup
      LoadBalancerAttributes: 
        - Key: "health_check_logs.s3.enabled"
          Value: "true"
        - Key: "health_check_logs.s3.bucket"
          Value: "amzn-s3-demo-logging-bucket"
        - Key: "health_check_logs.s3.prefix"
          Value: "logging-prefix"
```

------

## Step 4: Verify bucket permissions
<a name="verify-bucket-permissions-health-check"></a>

After health check 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 Amazon S3 console to verify that the test file was created. The test file is not an actual health check 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 bucket that you specified for health check logs.

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

## Troubleshooting
<a name="bucket-permissions-troubleshooting-health-check"></a>

If you receive an access denied error, the following are possible causes:
+ The bucket policy does not grant Elastic Load Balancing permission to write health check 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 health check logs. Verify that the resource ARN does not include a prefix if you did not specify a prefix when you enabled health check logs.
+ The bucket uses an unsupported server-side encryption option. The bucket must use Amazon S3-managed keys (SSE-S3).

# Disable health check logs for your Application Load Balancer
<a name="disable-health-check-logging"></a>

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

------
#### [ Console ]

**To disable health check logs**

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

1. In the navigation pane, choose **Load Balancers**.

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

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

1. For **Monitoring**, turn off **Health check logs**.

1. Choose **Save changes**.

------
#### [ AWS CLI ]

**To disable health check logs**  
Use the [modify-load-balancer-attributes](https://docs.aws.amazon.com/cli/latest/reference/elbv2/modify-load-balancer-attributes.html) command.

```
aws elbv2 modify-load-balancer-attributes \
    --load-balancer-arn load-balancer-arn \
    --attributes Key=health_check_logs.s3.enabled,Value=false
```

------