Lambda Logging in AWS [Default]

Lambda Logging in AWS

This example uses a very small AWS Lambda function named dummy_output to show what Lambda logs look like by default, why plain-text logs are sometimes not enough, and why structured logging becomes important once you need centralized observability.

Lambda function

The function prints a dummy message and returns a simple success response.

Function

def lambda_handler(event, context):
    print("Dummy Lambda output")
    return {
        "statusCode": 200,
        "body": "Dummy Lambda output",
    }


if __name__ == "__main__":
    print(lambda_handler({}, None))

Response

{
  "statusCode": 200,
  "body": "Dummy Lambda output"
}

Default log output

When the function runs, AWS Lambda automatically sends logs to CloudWatch. By default, those logs are often plain text and include both application output and platform/runtime details.

START RequestId: d386d5a9-2a75-41d1-TRIMMED Version: $LATEST
Dummy Lambda output
END RequestId: d386d5a9-2a75-41d1-TRIMMED
REPORT RequestId: d386d5a9-2a75-41d1-TRIMMED
Duration: 2.40 ms   
Billed Duration: 110 ms 
Memory Size: 128 MB 
Max Memory Used: 38 MB  
Init Duration: 106.81 ms

By default, these logs usually appear in a CloudWatch log group such as /aws/lambda/FUNCTION_NAME, In our case its /aws/lambda/dummy_output.

Why plain text is limited

Plain text is fine for quick debugging and small experiments. The problem starts when you need to centralize logs across multiple Lambda functions, search them efficiently, correlate events, or build dashboards and alerts.

At that point, unstructured text becomes harder to query and harder to enrich. A log pipeline can still ingest plain text, but it will usually need extra parsing rules to make the data useful.

Why structured logs help

If your application is fully Lambda-based and you want to understand how it behaves in production, structured logs are a better default.

JSON logs make it easier to:

• search by fields like Level, RequestId, Service, etc
• filter application errors without parsing free-form text
• send logs to a centralized platform
• build dashboards, alerts, and retention policies
• correlate application logs with platform and tracing data

Lambda logging configuration

AWS Lambda supports changing log formatting from the console:

Configuration -> Monitoring and operational tools -> Logging configuration -> Edit -> Log format -> JSON

A practical starting point is:

• Application log level: INFO
• System log level: WARN

That keeps routine noise down while still preserving useful runtime and platform information.

JSON log output

When JSON logging is enabled, the response from the function does not change, but the logs become much richer and easier to work with.

{
  "time": "2026-10-11T11:48:32.684Z",
  "type": "platform.initStart",
  "record": {
    "initializationType": "on-demand",
    "phase": "init",
    "runtimeVersion": "python:3.14.mainline.v75",
    "runtimeVersionArn": "arn:aws:lambda:eu-central-1::runtime:TRIMMED",
    "functionName": "dummy_output",
    "functionVersion": "$LATEST",
    "instanceId": "2026/10/11/dummy_output[$LATEST]TRIMMED",
    "instanceMaxMemory": 134217728
  }
}

You can also see the runtime start, execution, and final report details separately:

{
  "time": "2026-10-11T11:48:32.807Z",
  "type": "platform.report",
  "record": {
    "requestId": "5adc1477-4705-4710-TRIMMED",
    "metrics": {
      "durationMs": 1.914,
      "billedDurationMs": 102,
      "memorySizeMB": 128,
      "maxMemoryUsedMB": 38,
      "initDurationMs": 99.535
    },
    "status": "success"
  }
}

What this shows

This is not about doubting AWS Lambda itself. Lambda is already a managed serverless compute service, and AWS handles the platform for us.

The real reason to monitor it is different: our application logic is still ours. We still need to know when it fails, how it behaves under load?, what it returns?, and how it performs over time?.

If 100% or majority of our application runs on Lambda, centralized logging becomes essential for:

• troubleshooting failures
• tracing request paths across services
• understanding latency and cold starts
• detecting patterns in errors or retries
• supporting audit and operational visibility

Notes:

The default CloudWatch Logs destination keeps the standard CloudWatch Logs experience, including Logs Insights and Live Tail. Query cost is separate, so broad or repeated searches can increase the total.

Conclusion

For quick experiments, plain text logs are acceptable.

For production, JSON logs are usually a better choice because they are easier to aggregate, query, and route into a centralized observability stack.

If the goal is to operate a Lambda-based application at scale, structured logging should be the default rather than an afterthought.

Feel free to share your thoughts, happy learning!