While developing your lambda functions, debugging may become a problem. As a person who benefits a lot from step-by-step debugging, I had difficulty debugging lambda functions. I got lost in the logs. Redeploying and trying again with different parameters over and over... then, I found the AWS Serverless Application Model (SAM) Command Line Interface (CLI). The AWS SAM CLI lets you debug your AWS Lambda functions in a good, old, step-by-step way.

If you don’t know AWS SAM CLI, you should definitely check it out here. Basically, using SAM CLI, you can locally run and test your Lambda functions in a local environment that simulates the AWS runtime environment. Without the burden of redeploying your application after each change, you can develop faster in an iterative way.

Here, we will specifically debug a Python Lambda function. Before you proceed make sure that you installed AWS SAM CLI, let's move on:

1. Add a Visual Studio Code launch configuration

In order for the VS Code debugger to be attached to the simulated AWS runtime environment, we should add a launch configuration. You can use the following launch configuration:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "SAM CLI Python Hello World",
            "type": "python",
            "request": "attach",
            "port": 5890,
            "host": "localhost",
            "pathMappings": [
                {
                    "localRoot": "${workspaceFolder}",
                    "remoteRoot": "/var/task"
                }
            ]
        }
    ]
}

2. Install the Python Tools for Visual Studio Debug (PTVSD) package

If you don’t have, install PTVSD server to your Lambda application. You can install it by using the following command in the root of your Lambda application:

pip install ptvsd -t .

3. Add PTVSD code

Next, we should add the following lines of code to the file that contains our Lambda handler. Basically, it makes our code wait until we connect to the debugger using VS Code.

Also, let’s add a breakpoint where you want the debugger to be stopped. However, make sure that the breakpoint is added somewhere after the initialization of PTVSD :

4. Invoke your function with the AWS SAM CLI

Let’s invoke our function using SAM CLI. Here, we should specify the port that we want to connect by specifying `-d` or `--debug-port`. By using the `-e` option, you can also specify the path of event.json that you want to call your Lambda function with :

sam local invoke -e event.json -d 5890

When you run this command, AWS SAM CLI sets up the environment and waits for the VS Code debugger to be attached.

5. Start debugger and connect to PTVSD

When you start the debugging tool in VS Code (F5 in macOS), it will connect to the port specified in the launch configuration file. Once VSCode debugger connects to the ptvsd run on simulated AWS runtime environment, our Lambda function that waits for us to connect will continue and hit the first breakpoint. We now have our good old step-by-step debugger waiting on the breakpoint! You can now step in, step over, add watches, and see variables just like we do while debugging regular applications.

Voila! We configured VS Code and AWS SAM CLI to locally debug your Python Lambda functions. However, there is an important point left. When you decided to deploy your Lambda function, be sure that you removed or commented out the following lines in your Lambda application:

ptvsd.enable_attach(address=('0.0.0.0', 5890), redirect_output=True)
ptvsd.wait_for_attach()

When you call ptvsd.wait_for_attach(), your Lambda function execution waits on that line and does not proceed further. Leaving this code in your program would cause your function to be stopped at that line and would cause your function to time out.

You finished local debugging and you want to see your function running on AWS. At this point, you will need to observe how your function is actually working with third-party libraries and AWS resources like SNS or DynamoDB. You can add Thundra layer in minutes with ease and start understanding how your function is interacting with system resources.

To sum up, it is handy to test your function locally and it is perfectly achievable with AWS SAM and VS Code. However, how would you test your functions on AWS? Thundra comes in at this point. Plugging handy tools when needed for your development process eases our job at Thundra drastically. Hope it also helps to the serverless community.