Introduction

AWS Lambda automatically sends print output and runtime logs to CloudWatch Logs, but it does not let you choose the default log stream name for those entries. If you need records to land in a specific log stream, you must call the CloudWatch Logs API yourself. That is possible, but it adds extra permissions, API calls, and failure cases to the function.

What Lambda Controls by Default

A normal Lambda function logs into the standard Lambda log group, which is usually named /aws/lambda/<function-name>. AWS then creates log streams based on the execution environment.

A basic example:

1import logging
2
3logger = logging.getLogger()
4logger.setLevel(logging.INFO)
5
6def lambda_handler(event, context):
7    logger.info("standard Lambda log")
8    return {"ok": True}

That output goes to a stream chosen by Lambda. You cannot make logger.info write to a handpicked stream name inside the default mechanism.

When Manual Stream Selection Is Justified

Writing to a specific stream can make sense when:

• multiple functions must write to one shared application stream
• an external process expects a known stream name
• you want application events separated from runtime logs

If none of those apply, stick with default Lambda logging. It is simpler and more reliable.

Writing to a Specific Stream with boto3

To target a specific stream, create or reuse a log group, create or reuse the stream, then call put_log_events.

1import time
2import boto3
3
4logs = boto3.client('logs')
5LOG_GROUP = '/custom/app'
6LOG_STREAM = 'billing'
7
8
9def ensure_group_and_stream():
10    try:
11        logs.create_log_group(logGroupName=LOG_GROUP)
12    except logs.exceptions.ResourceAlreadyExistsException:
13        pass
14
15    try:
16        logs.create_log_stream(
17            logGroupName=LOG_GROUP,
18            logStreamName=LOG_STREAM,
19        )
20    except logs.exceptions.ResourceAlreadyExistsException:
21        pass
22
23
24def write_log(message):
25    ensure_group_and_stream()
26    logs.put_log_events(
27        logGroupName=LOG_GROUP,
28        logStreamName=LOG_STREAM,
29        logEvents=[
30            {
31                'timestamp': int(time.time() * 1000),
32                'message': message,
33            }
34        ],
35    )
36
37
38def lambda_handler(event, context):
39    write_log('invoice-created')
40    return {'ok': True}

This works, but it turns logging into application logic. If CloudWatch Logs becomes slow or misconfigured, your function now feels that failure directly.

Required IAM Permissions

The Lambda execution role must be allowed to manage the custom log destination. Typical permissions include:

• 'logs:CreateLogGroup'
• 'logs:CreateLogStream'
• 'logs:PutLogEvents'

If the role only has the default basic Lambda logging policy, a custom group or stream may still fail depending on the exact resource policy attached.

Understand the Tradeoff

Manual log-stream selection is more fragile than default logging because it introduces new dependencies into the request path:

• the group may not exist yet
• the stream may not exist yet
• the function may be throttled by CloudWatch Logs API limits
• IAM may block the write
• a naming decision can create too much contention in one stream

That is why many teams prefer to keep the default Lambda streams and solve routing with structured logs, metric filters, or subscriptions instead.

Structured Logs Are Often Better

If your real goal is searchable application logs, emit structured JSON and let CloudWatch or downstream tooling filter it.

1import json
2import logging
3
4logger = logging.getLogger()
5logger.setLevel(logging.INFO)
6
7def lambda_handler(event, context):
8    logger.info(json.dumps({
9        'component': 'billing',
10        'event': 'invoice-created',
11        'invoice_id': 42,
12    }))
13    return {'ok': True}

This keeps the AWS-managed stream model intact while giving you much better queryability.

Common Pitfalls

• Expecting print or the default Lambda logger to write into a custom stream name.
• Forgetting to grant logs:CreateLogStream and logs:PutLogEvents for the custom destination.
• Creating or checking the log stream on every invocation without considering latency and retries.
• Using one hot shared stream for high-concurrency traffic and turning logging into a bottleneck.
• Solving a search problem with custom streams when structured JSON logs would be simpler.

Summary

• Default Lambda logging goes to AWS-managed CloudWatch streams, not a stream name you choose.
• To write to a specific stream, call CloudWatch Logs directly from your code.
• Custom stream logging requires explicit group and stream management plus IAM permissions.
• Manual logging adds latency and operational complexity to the function.
• For many workloads, structured logs in the default Lambda streams are the better design.