If you’ve ever built a serverless application, you know the “Inner Loop” struggle. You write code locally, zip it up (or use SAM/CDK), deploy it to the cloud, check CloudWatch logs, realize you missed a comma, and repeat.
For years, the “gold standard” of debugging Lambda was essentially adding print("HERE 1") and print("HERE 2") statements and crossing your fingers.
AWS recently released two game-changing features that finally bridge the gap between your local IDE and the AWS Cloud: Console-to-IDE and Remote Debugging. Here is how they work and why your workflow is about to get a lot faster.
The Problem: The Cloud-Local Gap
Local development is great for speed, but it’s an emulation. Your local machine doesn’t have the same IAM roles, VPC access, or security groups as your production environment. On the flip side, the AWS Console is great for quick edits, but it lacks the powerful linting, extensions, and version control of an IDE like VS Code.
Feature 1: Console-to-IDE
We’ve all been there: you’re poking around the AWS Lambda console, you make a quick change to a function to test something, and then you realize you need to bring that change back to your local environment.
The new Console-to-IDE feature (integrated via the AWS Toolkit for VS Code) allows you to transition seamlessly.
-
How it works: Directly from the Lambda console, you can now trigger an action that opens that specific function in your local VS Code.
-
Why it matters: No more manual downloading of ZIP files or copy-pasting code into a local file. It establishes a direct link, ensuring your local environment matches what’s actually live in the cloud.
Feature 2: Remote Debugging (The Game Changer)
This is the feature developers have been asking for since 2014. You can now set a breakpoint in your local IDE, trigger a Lambda function running in the cloud, and have the execution pause at your breakpoint on your local screen. More details here.
Why this is better than local emulation:
-
VPC Resources: If your Lambda needs to talk to a private RDS database or an ElastiCache cluster inside a VPC, you can now debug that connection live.
-
IAM Permissions: No more guessing why a “Permission Denied” error is happening locally. You are debugging with the actual IAM role assigned to the function.
-
No Code Changes: You don’t need to add “debugger” libraries or modify your handler to make this work.
To start debugging, enable Remote Debugging when invoking your function through the AWS Toolkit. Set your local code path, define the payload, and hit Remote Invoke.
Behind the scenes, AWS Toolkit does a surprising amount of heavy lifting:
- Adds a temporary AWS-managed debugging layer to your Lambda
- Extends the function timeout
- Publishes a temporary debug version
- Reverts all changes once you’re done
It then invokes this debug version so you can start debugging immediately. No ritual sacrifices required.
A secure connection is established between your local debugger and the cloud function using AWS IoT Secure Tunneling. When you finish your session, the temporary version is automatically cleaned up. If you forget (very on brand for humans), the session ends after 60 seconds of inactivity or when the function times out.
