Web Function logs in Amazon CloudWatch Logs

AWS Lambda captures everything your application writes to standard output and standard error and sends it to Amazon CloudWatch Logs, along with system logs that Lambda itself generates. In Node.js, output from every console method, such as console.log, console.info, and console.error, is captured automatically and filtered by the applicationLogLevel setting. Logging libraries that write to standard output or standard error are also captured. You do not need a logging agent or the Amazon CloudWatch Logs SDK.

Lambda writes console output as JSON log events and adds the requestId, endpointName, and region fields to each event. For an example, see Writing structured logs.

Lambda collects logs in each AWS Region where your Web Function runs and then centralizes them into the function's home Region. A HomeRegion endpoint runs only in the home Region. A MultiRegion or PerRegion endpoint also runs in the other Regions that you specify, so Lambda centralizes logs from each of those Regions. For more information, see Endpoint types.

Log groups

By default, Lambda sends your Web Function's logs to a log group named after the function:

/aws/lambda/web/function-name

Alongside the centralized log group, Lambda uses a companion log group to hold in-Region logs before they are centralized. The companion's name is the centralized log group's name followed by .local, for both the default log group and a custom log group. For the default log group, the companion is:

/aws/lambda/web/function-name.local

Lambda writes logs to the .local log group in every Region where requests run, including the home Region, and then centralizes them into the log group without the suffix in the home Region. Each .local log group holds only the logs from its own Region. Lambda does not remove events from the .local log group after centralization. The log group's retention setting determines how long they remain.

The log groups do not exist until your Web Function serves its first request. The centralized log group in the home Region might appear after the .local log group. For centralization timing, see Centralization latency.

Lambda creates the default log group and each .local log group with default Amazon CloudWatch Logs settings, so their events never expire unless you set a retention policy. You can change their retention, encryption, and resource policy after Lambda creates them. Set these on the .local log group in every Region where the endpoint runs and on the centralized log group in the home Region.

Because the .local log group does not wait for centralization, it is useful for debugging an issue in a specific Region. The centralized log group holds logs from every Region, so build shared queries, subscription filters, metric filters, and automation that must cover the whole application on the centralized log group. For how telemetry behaves in each Region, see Telemetry in each Region.

Using a custom log group

You can send your Web Function's logs to a log group that you choose instead of the default. Use a custom log group when you want retention, encryption, or resource policies in place before the first log event arrives. A custom log group also lets you group logs from several functions together. To apply those settings from the start, create the log group and its .local companion yourself before you route traffic to the revision. If either log group does not exist, Lambda creates it on first use with default settings, and you can update its settings afterward. Lambda can create a log group only if the execution role has permission to create log groups. For the required permissions, see Execution role.

Because logging configuration is part of the revision, it is immutable for that revision. To change the log group later, create another revision. For more information, see Managing Web Function revisions.

Logging controls

The loggingConfig section controls the destination and minimum severity of logs. These settings are part of the revision.

The following example creates a revision that drops application logs below WARN:

aws lambda-web create-web-function-revision \
    --function-name my-web-app \
    --build-config '{
      "codeConfig": {
        "s3Object": { "bucket": "my-bucket", "key": "my-app.zip" }
      },
      "runtimeConfig": { "runtime": "nodejs24.x" }
    }' \
    --service-config '{
      "executionRoleArn": "arn:aws:iam::111122223333:role/my-web-function-role",
      "telemetryConfig": {
        "loggingConfig": {
          "applicationLogLevel": "WARN",
          "systemLogLevel": "INFO"
        }
      }
    }'

Raising applicationLogLevel in production reduces both log volume and cost. Lower it temporarily to DEBUG or TRACE when you are investigating an issue.

System logs

In addition to your application's output, your log group receives system logs that Lambda generates about the execution environment lifecycle, such as environment initialization and shutdown. Use systemLogLevel to control how much of this Lambda emits.

System logs are useful for correlating application behavior with platform events. For example, a latency spike that lines up with an environment initialization entry points to a cold start rather than to your application code. For the lifecycle these logs describe, see Execution environment lifecycle.

Web Functions emit the following system events. Set systemLogLevel to the lowest level that you need. For example, set it to DEBUG to receive platform.requestComplete, or to WARN to receive only failures and dropped-log warnings.

For the fields in each system event, see System log event schema for Lambda Web Functions.

The lambda-web-request-id response header identifies the request, and the lambda-web-logstream response header identifies the log stream for the environment that handled it. Use these values to correlate a client response with application and system logs. For more information, see Response headers.

To find the events from the identified log stream in the centralized log group in the home Region, filter by the stream name as a prefix. You can also read the stream by its exact name from the .local log group in the Region that served the request.

aws logs filter-log-events \
    --log-group-name /aws/lambda/web/my-web-app \
    --log-stream-name-prefix "LAMBDA_WEB_LOGSTREAM" \
    --region us-east-1

To follow recent logs while reproducing an issue, use:

aws logs tail /aws/lambda/web/my-web-app \
    --follow \
    --region us-east-1

Writing structured logs

Pass an object to a console method so that Lambda writes it as a JSON object in the message field. You can then query individual fields in Amazon CloudWatch Logs Insights rather than matching on substrings. Do not pass a string that you built with JSON.stringify. Lambda writes a string as an escaped string value, so its fields cannot be queried.

function logRequest(req, statusCode, durationMs) {
  console.info({
    method: req.method,
    path: req.url,
    statusCode: statusCode,
    durationMs: durationMs
  });
}

Lambda writes a log event similar to the following:

{
  "timestamp": "2026-09-25T11:29:02.711Z",
  "level": "INFO",
  "message": {
    "method": "GET",
    "path": "/hello-world",
    "statusCode": 200,
    "durationMs": 100
  },
  "requestId": "US3NHLM77IRXDFLBADYHGIZZNM",
  "endpointName": "prod",
  "region": "us-east-1"
}

You can then query the fields directly. For example, the following Amazon CloudWatch Logs Insights query returns the 20 most recent requests that returned a 5xx status:

fields @timestamp, message.method, message.path, message.statusCode, message.durationMs
| filter message.statusCode >= 500
| sort @timestamp desc
| limit 20

To publish custom metrics from your logs rather than only querying them, use the embedded metric format. For more information, see Publishing custom metrics with the embedded metric format.

Using Amazon CloudWatch Logs features with your logs

Because logs are centralized into the home Region, you can use the standard Amazon CloudWatch Logs features in that Region, including:

Apply features that must cover the whole application to the centralized log group in the home Region. A .local log group holds only the logs from its own Region. For more information, see Telemetry in each Region.