If you don't have an option to modify the lambda code itself and don't mind a bit of added complexity, you could explore the Lambda Extentions API:
As an extension author, you can use the Lambda Extensions API to integrate deeply into the Lambda execution environment. Your extension
can register for function and execution environment lifecycle events.
In response to these events, you can start new processes, run logic,
and control and participate in all phases of the Lambda lifecycle:
initialization, invocation, and shutdown. In addition, you can use the
Runtime Logs API to receive a stream of logs.
Also, see the blog post about AWS Lambda Extensions which states:
You can use extensions for use-cases such as:
- capturing diagnostic information before, during, and after function
invocation
- automatically instrumenting your code without needing code changes
Another option would be to create an register a lambda layer, then add code in the layer to modify the logging level for the default logger that the function uses. Layers run before the lambda handler execution.
Within the function itself you may not be able to do this without making some sort of code change since the code itself may be setting log levels or using particular logging libraries/tools. Even lambda functions I've seen provided by AWS have code that looks for an environment variable and sets the log level accordingly. If you don't want that dive into extensions and can make a minor change to the function code, I like an approach like this that uses a fallback default value ("INFO" in this case):
logger = logging.getLogger()
logger.setLevel(os.getenv('log_level', 'INFO').upper())
logger.debug('will be logged if the "log_level" env var is set to DEBUG')