AWS Cloud Operations Blog

Analyze Application Load Balancer Logs with Amazon CloudWatch Logs

Summary

​Amazon CloudWatch Logs now supports Application Load Balancer (ALB) logs as vended logs, giving you out-of-the-box visibility into the health and performance of your ALB. All three ALB log types (access, connection, and health check) are delivered as structured JSON with named fields. This allows teams to attribute 5xx errors to the load balancer or the application, identify routes contributing to high latency, and diagnose failing health checks. No Amazon S3 bucket management, Amazon Athena table setup, or custom ETL pipelines are required.

The dashboard below shows request volume and status code distribution, error trends with load balancer vs. target attribution, per-route latency percentiles, target health outcomes, and top client/target rankings. It is deployed using the AWS CloudFormation template provided in this post.

ALB Insights dashboard showing request volume, error analysis, and latency breakdown across load balancers

Figure 1: ALB Insights dashboard showing request volume, error analysis, and latency breakdown across load balancers

Introduction

An Application Load Balancer sits on the request path of most customer-facing workloads on AWS. It sees every request before your application does, including requests that never reach a target. When a service degrades, ALB logs answer the first question an on-call engineer asks: is this the load balancer, the network, or my application?

ALB emits three log types:

  1. Access logs 
  2. Connection logs 
  3. Health check logs 

Before this launch, these logs went to Amazon S3 as compressed, space-delimited files. You managed lifecycle policies, maintained Athena tables as ALB appended fields, and built separate infrastructure for alerting. Now, ALB records land in the same place as your VPC Flow Logs, AWS WAF logs, and application logs, inheriting everything CloudWatch Logs already provides: Log Analytics, metric filters, Contributor Insights, Live Tail, anomaly detection, and cross-account cross-region centralization.

Getting started: Enable and deploy

In this section, we walk through enabling ALB log delivery with a telemetry enablement rule and deploying the sample dashboard with the provided CloudFormation template.

Step 1: Enabling ALB Log Ingestion via Telemetry Enablement Rules

​Amazon CloudWatch telemetry enablement rules allow you to automatically configure telemetry collection for your AWS resources. Rules help you standardize telemetry collection across your organization and provide consistent monitoring coverage. A single rule configures delivery on existing and newly created load balancers in its scope, so enabling logging once covers the load balancers a deployment pipeline creates later.

Follow these steps to enable ALB log ingestion into CloudWatch:

  1. Open the CloudWatch console in your management or delegated administrator account.
  2. In the navigation pane, choose Ingestion, then the Enablement rules
  3. Choose Add rule.
  4. For Data source, choose Amazon Elastic Load Balancer – Application and click Configure Telemetry.
  5. For Rule name, enter a descriptive name (for example, ALB-Logs-Enablement).
  6. For Rule scope, choose Organization, Organizational unit, or Account.
Step 1, Specify scope, with the rule name, source accounts, optional data source tags, and target Regions

Figure 2: Step 1, Specify scope, with the rule name, source accounts, optional data source tags, and target Regions

  1. Configure the log group name pattern, retention, and output format, then review and create the rule.
  2. For Telemetry type, choose Logs, then select the log types you want (Access, Connection, Health Check).
  3. (Optional) Add tag key/value pairs to scope the rule to a subset of load balancers (for example, Environment: Production).
Step 2, Specify destination, with the log group name pattern, retention, encryption, and selection of the three ALB log types

Figure 3: Step 2, Specify destination, with the log group name pattern, retention, encryption, and selection of the three ALB log types

  1. Review and click Configure Amazon Elastic Load Balancer – Application logs
Step 3, Review and create, summarizing the rule name, source accounts, target Regions, CloudWatch Logs destination, and selected log types

Figure 4: Step 3, Review and create, summarizing the rule name, source accounts, target Regions, CloudWatch Logs destination, and selected log types

Once the enablement rule is active, CloudWatch begins ingesting ALB logs from resources within the rule’s scope. The logs are automatically transformed into structured JSON format and stored in a CloudWatch Logs log group. All three log types land in the same log group, separated by log stream prefix:

  1. Access logs – ALB_Access_Logs/app/<lb-name>/<lb-id>
  2. Connection logs – ALB_Connection_Logs/app/<lb-name>/<lb-id>
  3. Health check logs – ALB_Health_Check_Logs/app/<lb-name>/<lb-id>

Step 2: Deploy the CloudWatch dashboard via CFN template

​CloudWatch Dashboards provide a unified visualization layer for your ALB log data. The sample dashboard uses CloudWatch Log Analytics queries, metrics and Contributor Insights rules to surface operational patterns across all your monitored load balancers, giving your operations team a single destination to monitor traffic, investigate errors, and validate target health.

ALB insights dashboard, showing request volume, 5xx error count, worst target p99 latency, status code distribution, and health check detail

Figure 5: ALB insights dashboard, showing request volume, 5xx error count, worst target p99 latency, status code distribution, and health check detail

To help you get started quickly, we have provided a CloudFormation template that deploys the dashboard

  1. Download the CloudFormation YAML template.
  2. Open the AWS CloudFormation console.
  3. Choose Create stack > With new resources (standard).
  4. Upload the template and choose Next.
  5. Enter a stack name and configure the parameters:
    1. DashboardName – Name of the dashboard (default: ALB-Insights)
    2. DefaultTimeRange – Time range the dashboard opens on (default: -PT3H)
    3. CreateContributorInsightsRules – Yes to add Contributor Insights rules; Nofor dashboard only
    4. ALBLogGroupName – Log group receiving ALB logs (default: /aws/elb). Used only by Contributor Insights rules.
    5. ResourcePrefix – Prefix for rule names (default: ALB)
  6. Choose Next, configure any stack options as needed, then choose Next
  7. Review your configuration and choose Submit.

Once the stack creation completes, the CloudWatch dashboard is available and ready to display your ALB log patterns as events are delivered.

CloudFormation Resources tab showing the dashboard and both Contributor Insights rules with CREATE_COMPLETE status

Figure 6: CloudFormation Resources tab showing the dashboard and both Contributor Insights rules with CREATE_COMPLETE status

Analyzing ALB Logs with Log Analytics

With the dashboard deployed, you can also run ad-hoc queries directly. Open Logs > Log Analytics in the CloudWatch console. Here are the queries that answer the most common operational questions.

Is the 5xx from the load balancer or the application?

SOURCE logGroups()
| filterIndex @data_source_name in ["aws_alb"]
| filterIndex @data_source_type in ["access"]
| filter elb_status_code >= 500
| parse elb /^app\/(?<lb>[^\/]+)/
| fields if(target_status_code = "-", "load balancer / network", "target application") as owner
| stats count(*) as errors,
        count_distinct(target_port) as targets_affected,
        earliest(time) as first_seen,
        latest(time) as last_seen
        by owner, lb, elb_status_code
| sort errors desc

Which routes are slow?

SOURCE logGroups()
| filterIndex @data_source_name in ["aws_alb"]
| filterIndex @data_source_type in ["access"]
| filter target_processing_time >= 0
| parse request_line /^(?<method>\S+)\s+(?<url>\S+)/
| parse url /^[a-z]+:\/\/[^\/]*(?<path>[^?]*)/
| parse path /^\/(?<s1>[^\/]*)\/?(?<s2>[^\/]*)/
| fields if(s2 = "", concat("/",s1), concat("/",s1,"/",s2)) as route
| stats count(*) as requests,
        avg(target_processing_time)*1000 as avg_ms,
        pct(target_processing_time,90)*1000 as p90_ms,
        pct(target_processing_time,99)*1000 as p99_ms,
        max(target_processing_time)*1000 as max_ms
        by route
| sort p99_ms desc
| limit 15

Per-target reliability combining access and health check logs

SOURCE logGroups()
| filterIndex @data_source_name in ["aws_alb"]
| filterIndex @data_source_type in ["access","health_check"]
| fields coalesce(target_port, target_addr) as target
| filter ispresent(target)
| parse elb /^app\/(?<lb>[^\/]+)/
| stats count(request_line) as requests,
        sum(elb_status_code >= 500) as errors_5xx,
        sum(elb_status_code >= 500)*100.0/count(request_line) as error_pct,
        pct(target_processing_time,99)*1000 as p99_ms,
        count(status) as probes,
        sum(status = "FAIL") as probe_failures
        by lb, target
| sort probe_failures desc, errors_5xx desc
| limit 20

Using Log alarms for alerting ALB health check failures

CloudWatch Log Alarms let you create alarms directly from a Log Analytics query with no custom metrics required. The query runs on a schedule, an aggregation expression produces a numeric value, and the alarm fires when that value breaches a defined threshold. Log Alarms use the same query language as Log Analytics, with no additional cost for custom metric ingestion or storage.

Example: Alarm on health check failures

  1. Open the CloudWatch console and navigate to Alarms > All alarms.
  2. Choose Create alarm, then choose Logs as Data source.
  3. Click Create query in Log Analytics
  4. Run the below query and click Continue to Alarms
SOURCE logGroups()
| filterIndex @data_source_name in ["aws_alb"]
| filterIndex @data_source_type in ["health_check"]
| filter status = "FAIL"
| stats count(*) as probe_failures by elb
  1. For Aggregation expression, enter sum(probe_failures).
  2. For Alarm Conditions, choose Greater than and enter 0.
  3. For Schedule, choose a frequency (for example, rate(5 minutes)).
  4. Set StartTimeOffset to 300 seconds (matches the 5-minute schedule).
  5. For M out of N, set to 1 out of 1 to alarm on the first occurrence.
  6. Configure an Amazon SNS topic for notifications.
  7. Choose Create alarm.

The alarm now evaluates your query every 5 minutes and fires when any health check probe fails.

(Optional) Expanding Capabilities

The enablement rule and CloudFormation template are sufficient to get started. The following sections describe optional capabilities for teams that want to go further.

Enrich ALB Logs at Ingestion with a Pipeline

CloudWatch Logs pipeline processes ALB records at ingestion, letting you enrich, transform, or reshape fields before they reach your log group.

Create a pipeline

  1. Open the CloudWatch console and navigate to Ingestion > Pipelines.
  2. Choose Create pipeline.
  3. On the Getting started page:
    • For Select data source, choose AWS Application Load Balancer logs.
    • For Log source type, choose the log type you want to enrich (Access, Connection, or Health Check).
    • For Service access, choose Auto create and use a new service role to let CloudWatch create the required IAM role.
  4. Choose Next to configure the pipeline destination and log group settings.
  5. On Configure processors page, add processors to transform the data. Below are sample processors that are useful for ALB logs:
    1. Convert Type (Mutate Events) – Converts elb_status_code from string to integer so that numeric comparisons in metric filters (for example, { $.elb_status_code >= 500 }) evaluate correctly.
    2. GeoIP (Enrich) – Adds geographical information (country ISO code, city name, ASN organization) to records based on the client_ip field, writing the result to a new client_geo Use a conditional expression (client_ip != "") to skip records where the field is empty. This lets you answer “where is my traffic coming from?” directly in your queries without maintaining an external IP lookup.
    3. Translate (Mutate Events) – Maps elb_status_code values to a human-readable elb_status_meaning field using static mappings (for example, 503 -> “no_registered_or_healthy_targets”). Add a run-when condition (elb_status_code != "" and elb_status_code != "200") so the processor only runs on error responses, keeping the field absent on successful requests to reduce noise.
Configure processors page with Parse JSON, Convert Type, and GeoIP processors added

Figure 7: Configure processors page with Parse JSON, Convert Type, and GeoIP processors added

  1. Choose Test processors to validate your configuration against sample log events before saving.
  2. Review and create the pipeline.

Centralize ALB Logs into One Account

If you run workloads across multiple accounts, CloudWatch Logs centralization consolidates log groups from multiple accounts and Regions into one destination account. Centralized log groups are enriched with @aws.account and @aws.region fields, so a platform team can query the entire fleet from one place.

For detailed steps, see Simplifying log management using Amazon CloudWatch Logs centralization.

Contributor Insights

Contributor Insights continuously ranks the top-N contributors to a pattern. The template creates two rules:

Rule Key field What it ranks
TopClientIPs-ConnectionLogs $.client_ip Top client IPs by connection count (from connection logs)
TopTargetsByRequests-AccessLogs $.target_port Top targets by request volume (from access logs)

To create the top client IPs rule manually:

  1. Open the CloudWatch console and navigate to Insights > Contributor Insights.
  2. Choose Create rule.
  3. For Rule name, enter ALB-TopClientIPs-ConnectionLogs.
  4. Under Log group(s), select your ALB log group (for example, /aws/elb).
  5. For Log format, choose JSON.
  6. For Aggregate on, choose Count.
  7. Under Contribution:
    1. For Key, enter $.client_ip.
  8. Under Filters, add a filter:
    1. For Match, enter $.client_ip.
    2. For Condition, choose IsPresent = true.
  9. Choose Create rule.
The TopClientIPs-ConnectionLogs rule ranking the top 10 client IPs by connection count over a three-hour window

Figure 8: The TopClientIPs-ConnectionLogs rule ranking the top 10 client IPs by connection count over a three-hour window

Cleanup

To stop charges, remove resources in this order:

  1. Delete the telemetry enablement rule from Ingestion > Enablement rules.
  2. Delete the pipeline from Ingestion > Pipelines, if you created one.
  3. Delete the CloudFormation stack (removes the dashboard and Contributor Insights rules).
  4. Delete the ALB log groups or set short retention.

Conclusion

ALB access, connection, and health check logs now deliver directly into CloudWatch Logs as structured JSON, giving you request-level, connection-level, and target-level visibility into your workload’s entry point. A single enablement rule covers every load balancer in your AWS organization. Log Analytics separates load balancer faults from application faults. Log Alarms notify you when something breaks. Contributor Insights ranks the clients and targets driving your traffic. No pipelines, no parsing, no additional infrastructure.

To get started, open the CloudWatch console, navigate to Ingestion > Enablement rules, and create a rule for your Application Load Balancers. For more information, see the Amazon CloudWatch Logs documentation.

Raviteja Sunkavalli

Raviteja Sunkavalli

Raviteja Sunkavalli is a Senior Worldwide Specialist Solutions Architect at Amazon Web Services, specializing in AIOps and GenAI observability. He helps global customers implement observability and incident management solutions across complex and distributed cloud environments. Outside of work, he enjoys playing cricket and exploring new cooking recipes.

Siva Guruvareddiar

Siva Guruvareddiar

Siva Guruvareddiar is a Senior Solutions Architect at AWS where he is passionate about helping customers architect highly available systems. He helps speed cloud-native adoption journeys by modernizing platform infrastructure and internal architecture using microservices, containerization, observability, service mesh areas, and cloud migration. Connect on LinkedIn at: linkedin.com/in/sguruvar