Logging - Serverless Architectures with AWS Lambda


Each language runtime for Lambda provides a mechanism for your function to deliver logged statements to CloudWatch Logs. Making adequate use of logs goes without saying and isn’t new to Lambda and serverless architectures. Even though it’s not considered best practice today, many operational teams depend on viewing logs as they are generated on top of the server an application is deployed on. That simply isn’t possible with Lambda because there is no server. You also don’t have the ability to “step through” the code of a live running Lambda function today (although you can do this with AWS SAM Local prior to deployment). For deployed functions, you depend heavily on the logs you create to inform an investigation of function behavior. Therefore, it’s especially important that the logs you do create find the right balance of verbosity to help track/triage issues as they occur without demanding too much additional compute time to create them.

We recommend that you make use of Lambda environment variables to create a LogLevel variable that your function can refer to so that it can determine which log statements to create during runtime. Appropriate use of log levels can ensure that you have the ability to selectively incur the additional compute cost and storage cost only during an operational triage.